Explicit call-out about syntactic diffs from legacy implementations? (unmodified ExportDeclaration)

[bathos]

In the current spec, the modified productions are PropertyDefinition:MethodDefinition, ClassDeclaration, ClassExpression, and ClassElement, all of which may begin with an optional DecoratorList.

The current spec text includes this example of usage in Aurelia at EXAMPLE 2 (INFORMATIVE):

@customElement('nav-bar')
export class NavBar {}

@useShadowDOM
@customElement('my-expander')
export class Expander {
  @bindable isExpanded = false;
  @bindable header;
}

My understanding is that these examples (being marked as "informative") are meant as illustrations of real-world usage/need and do not necessarily need to match up with the proposal itself (and syntactically, this example does not). But I think it illustrates something that would benefit from an explicit call-out in the text.

The syntax which was implemented in Babel 5 (and the subsequent Babel 6 plugin) and TypeScript modifies a slightly different set of productions. They modify ExportDeclaration to permit an initial DecoratorList in the seventh alternative, and further it is implied that ClassDeclaration is parameterized (e.g. [Decorators]) and that it is referenced with [+Decorators] everywhere but in this case, which is [~Decorators]; that is, they specifically disallow a DecoratorList to begin a class declaration when the class declaration is the body of an ExportDeclaration.

Thus the Aurelia example places decorators before "export" instead of after it, as they would in the decorators proposal as it reads today. Since the Babel 5 / TS syntax has become common in real-world code (and, as far as I know, is the only syntax that has seen a realization to date), an explicit note about this difference may be valuable.

[littledan]

Good catch. Do you think we made a decent call in the syntax change here, or is the old syntax better?

Basically everything is different between the earlier decorators specification and this one. You just have to read the new specification to understand how it works. Probably it's a good idea for someone to write such a differences document, but for now reading the whole thing is best.

[bathos]

Do you think we made a decent call in the syntax change here, or is the old syntax better?

Was this actually a change? AFAICT, even the earliest versions of the decorator proposal that included grammar used the current format. I believe it was just implemented incorrectly in Babel/TS, or perhaps was implemented before the grammar was defined at all and assumptions were made. Maybe there’s more history that I can’t find, but it doesn’t seem to be a recent change anyway.

In any case I do think the proposed syntax is superior to what’s been implemented. I could imagine that some might feel it is slightly less attractive, but it is much more logical: it is a class decorator, not an export decorator or a binding decorator — and if any such thing were to someday be added, we’d be in a tough spot.

[littledan]

Let's move discussion to tc39/proposal-decorators#50 .