This comment has been minimized.

This isn't included in the ES7 proposal and TypeScript have added it by themselves. I think this is extremely dangerous and they're going to fuck over their users as the spec is in extreme flux and semantics are changing. Adding an unspecced and highly controversial decorator extension is going to cause pain.

This comment has been minimized.

There doesn't seem to be an agreement on this at all if I look at the meeting protocol specially when it comes to the scope and dynamic nature of function parameters. There are no decorators for functions because of the hoisting issues. Currently frameworks work around this by using property decorators and effectively treat them as class method decorators (which when writing them also seems right), but effectively they are just property decorators. As long as there are no real function decorators, there won't be any function parameter decorators.

Constructors can't have decorators in the ES7 decorator proposal as they don't get defined as object properties and classes can only have decorators because the resulting constructor function is not hoisted. This is already confusing but after reading all those threads, the limitations seem to be quite hard and all pointing back to the hoisting issues.

Let's say, just hypothetically, that TC39 agrees on the "workaround" of treating all functions with decorators on them as function expressions and don't hoist them. Then there would possibly be a solution where function and function parameter decorators could exist. However, there will be a conflict with property descriptors I guess, because how would JavaScript know if you're defining a function decorator or a property decorator when a function is defined inside a class? Maybe the short hand class { @A() a() {} } could assume function level decorators and class { @A() a: function() {} } would assume class property level? Still not very clean I guess.

I wonder how TypeScript implemented this? I'm still trying to keep things pure ECMAScript but having function and function parameter decorators is just really nice for framework API design and tooling support. I really hope that there's a super brain somewhere who finds a good solution for this issue.

This comment has been minimized.

I spoke to @jonathandturner about this. According to him, the tc39 decided decorators are going to be in two chunks. Chunk 1 is classes, class members, and maybe class properties. Chunk 2 is parameter decorators, maybe function decorators, etc. which likely needs more work in the reflection system.

I say it's too early to be talking about this. I also haven't heard much interest outside of the Angular team so I'm bearish on this ever being part of the standard.

[[ https://docs.google.com/document/d/1Qpkqf_8NzAwfD8LdnqPjXAQ2wwh8BBUGynhn-ZlCWT0/edit | The stage 0 proposal]] doesn't specify how parameter decorators should work but it shows the syntax.

Is it acceptable to add only parser support first and implement appropriate transform when the proposal becomes implementable? If only babylon parses the syntax, people can start building transform plugins, like Angular 2 annotation, on top of it.

@shuhei the actual transform is still being debated. TypeScript implements one, but I expect that it will still change. Ron Buckton from MS has a Mirrors proposal which seems like the best way forward for this as well as several other decorator related transforms so we will most likely end up heading in that direction.