RFC: Attributes

[Mooshua]

Rendered link

First draft of attribute RFC. This is very similar to how decorators were handled in JavaScript. This is marked as a draft until scope, desired features and feasibility is better understood.

TODO:

• Do we want to allow annotating types? How would this be handled by the runtime? Would this be reserved only for the typechecker?
• Do we want to trade any dynamic properties of attributes for constants/compile-times to increase performance or debugability?
• Can attribute-laden code be feasibly debugged?

I am very interested in hearing your thoughts, use cases, and criticisms for this proposal. Thanks!

Note: This RFC collides with #807 so do not merge without resolving that first.

[Mooshua]

Hi @alexmccord, I saw you added the RFC tag to the other PR. Would you mind also adding it to this one? Thanks.

[zeux]

This PR is closed as part of RFC migration; please see #1074 (comment) for context.

Additional notes: I don't think we should be using the word "attributes" for this; I would propose a vocabulary where annotations mean "type annotations", attributes mean a specific fixed set of extra information that is known by the compiler or type checker and modifies the compilation, runtime or type checking/linting behavior, and decorators mean user-controlled runtime-visible data that attaches to functions/variables/etc.

With that in mind, this RFC seems to mix attributes and decorators, seems very wide in scope, doesn't seem to specify semantics of some use cases proposed (how does @Default work?). Specifically for decorators, it's not clear to me that existing ways to specify DSLs through short-hand syntax along with actual explicit function calls are insufficient, and it's not clear to me what we will do with most decorators proposed here. For example, @Constructor is written as if it somehow modifies behavior of the function but it's unclear how that works / what that does. The serialization decorators are written as if they attach to keys/values of the table but that seems to imply that every table key/value will now need to store an extra "decorator" value, which is prohibitive at runtime.

Overall, this RFC seems to have a very wide scope so I may have gotten some of the above wrong, but I would recommend specifying attributes per vocabulary above (see linked RFC, although that one is unfortunately called "annotations"), and ignore user-specified syntax expansions for now.