We have a need for passing enums to decorators to support the "extensible enum" pattern - a value that is effectively a string or number, but which has some known and documented values. Passing an enum expression to a decorator is a convenient way to achieve this.
All of our current declarations may have similar use cases, and anyway being consistent about allowing expression forms for declarations seems like a good thing.
Semantically, expression forms are not declarations, but may still be named. This ensures that declarations which introduce bindings are still easily visible (and not affected by deeply nested expressions).
Example syntax:
@extensible(enum Options { @dec a, b })
model MyEnum is string;
model Foo {
x: model Bar { }
}
Potential issues:
- Without the ability to decorate arbitrary expressions, you cannot have decorated expression forms. Adding expression-level decorators would require some careful design on its own.
- Emitters may still treat expression forms as declarations. E.g. if we do the simple thing, the
Foo example above will likely result in a schema for a model Bar. This may be problematic because finding the actual source for this declaration may be difficult.
We have a need for passing enums to decorators to support the "extensible enum" pattern - a value that is effectively a string or number, but which has some known and documented values. Passing an enum expression to a decorator is a convenient way to achieve this.
All of our current declarations may have similar use cases, and anyway being consistent about allowing expression forms for declarations seems like a good thing.
Semantically, expression forms are not declarations, but may still be named. This ensures that declarations which introduce bindings are still easily visible (and not affected by deeply nested expressions).
Example syntax:
Potential issues:
Fooexample above will likely result in a schema for a modelBar. This may be problematic because finding the actual source for this declaration may be difficult.