00:00
<littledan>
All of the decorators serve the same purpose as a keyword might. There was a strong sentiment in the past by some committee members that once Decorators is at Stage 4 we should avoid adding new keywords for things if a decorator would suffice. While I'm not sure I 100% agree, decorators could be used for this.
This very much has to be a case by case thing. I think Shu has technical reasons here why decorators don’t work. (Also I don’t know why your decorators have ()—that has never been needed in any draft proposal that I saw for decorators, and isn’t needed in Stage 3 or TS decorators)
00:02
<rbuckton>

That's fair, though I'll admit that in the TS experiment I'm using decorators so that I can use class so that TypeScript understands the types produced. The @Shared decorator itself is somewhat complex, but I can very easily write definitions like the following:

@Shared()
export class SharedTypeParameterDeclaration extends SharedNodeWithJSDoc<SyntaxKind.TypeParameter> {
    @Shared() readonly modifiers!: SharedNodeArray<SharedModifier> | undefined;
    @Shared() readonly name!: SharedIdentifier;
    @Shared() readonly constraint!: SharedTypeNode | undefined;
    @Shared() readonly default!: SharedTypeNode | undefined;
    @Shared() readonly expression!: SharedExpression | undefined;
}
00:04
<rbuckton>
So I'd argue that there aren't technical reasons why decorators won't work, at least not with the origin trial.
00:19
<rbuckton>
Let me walk that last statement back somewhat. Its technically feasible to implement using decorators, but may not have intended performance characteristics due to potential limitations in static analysis.
14:53
<Mathieu Hofman>
The biggest complication I see with piggy-backing on the class syntax is the same issue we keep running into: how do you connect a local behavior to a definition introduced by another thread. At the end of the day, class creates a local definition, which seem incompatible with attaching behavior, at least without introducing new syntax.