Comments are welcome here or on the MR for the proposal to ignore non-entrypoint annotations: Ignoring annotations (!138) · Merge Requests · TZIP / tzip · GitLab
4 Likes
I think this is a good move. Type annotations can give a false sense of security; in particular because ticket (nat :a) can be casted into ticket (nat :b) by going through ticket nat. Moreover, ignoring annotations in the protocol lowers the entry barrier for new protocol developers.
All existing tests and all on-chain contracts should still typecheck, produce
the same typed AST (modulo annotations), and have the same behaviour.
Of course, this is not strictly true. Previously CONTRACT (int :foo) would return None if the parameter type were declared as int :bar.
Conceivably you could rely on this… Maybe to enforce properties related to “view” callbacks, for example. But I doubt anyone is doing that.
I think this behavior is a bug waiting to happen anyway. The “non-transitive equality” is very strange. It means that e.g. two contracts can each be compatible with a standard interface, yet incompatible with each other.
Separate note: non-entrypoint annotations are still important for off-chain usage.
Micheline is better than binary, but it is still neither human-friendly nor program-friendly in some sense. Many kinds of users and tools really want to work with JSON-ish data, with names for record fields and variant cases.
This can happen it at least two ways:
For a fixed Michelson type, the annotations can help users and programs to author or manipulate data.
For varying Michelson types, the annotations can provide a kind of “interface” abstracting over the different “physical” layouts. One real example is the %metadata field standardized by TZIP-16.
If the non-entrypoint annotations are someday removed entirely, we’ll have to replace them with something (maybe something entirely or partly off-chain.)
4 Likes
