allow decorators for functions

[zpdDG4gta8XKpMCd]

did a quick search, it looks like this hasn't been yet requested

currently decorators can only be added to classes, methods and properties

consider allowing them on functions too

[tinganho]

@Aleksey-Bykov it was discussed in here #2249 (comment)

[mhegazy]

Please note that decorator proposal is undergoing churn now, and we would not be adding new features until we have a stable proposal.

[IgorMinar]

@mhegazy just fyi that function expression decorators are at stage 0: https://github.com/tc39/proposals/blob/master/stage-0-proposals.md

And while the underlying implementation is undergoing some churn, the syntax has been stable for quite a while. It would be great to have this implemented behind a flag because angular users could then write tests with a much nicer syntax.

it('should do foo', @Injectable()(fooService:FooService) => {
...
});

compared to the current:

it('should do foo', inject([FooService], (fooService:FooService) => {
...
});

[majo44]

Any progress ? This will be really powerful feature. There is a lot of use cases.
I see on roadmap just support for function expression/arrow functions :(
I know the problem is with function hoisting.
But I think we can loos hoisting for decorated functions (especially if we are using modules).
Compiler is able to detect decorated function hoisting (and cycles) and just throw error.
I beg, do not give up :)

Related discussion:
wycats/javascript-decorators/Allow decorators for functions as well

[Thinkscape]

This could potentially solve #10644 - it's a nasty side-effect when trying to use using bound methods feature with decorators :-(

[aluanhaddad]

My understanding of this issue is:
Decorators were added due mitigate the lack of expressiveness that was inherent in the maximally minimal approach to classes that TC39 took.

My crude paraphrasing of the above is:
ES2015 classes are basically useless without decorators. They are a travesty of a class implementation.

Do they offer conciseness? No.

Do they enable expressing anything that is not better expressed with factories? Not for me.

Do they offer compositional approaches aside from unmaintainable 5+ class deep hierarchies? No.

Do the enable composition over inheritance? No. (ignoring all the lessons learned in C++, C#, Java)

Do they encourage depending on implementation? Yes!

Do they provide encapsulation? No.

The Maximally Minimal appraoch fell flat on its face. The only reason to use classes is to use decorators, the feature has been proposed to make up for how worthless they are.

[aluanhaddad]

Wow, that was a fast 3 👎.
UPDATE: 2 👎 (thanks @majo44 for reconsidering 😆)

I am not saying decorators should not be allowed on functions.
I am saying that the reason they are not is because they were only added to make up for classes being useless.

Again Maximally Minimal approach to decorators is what leads that feature to be insufficiently generalizable to other constructs.
I would like to have function decorators.
I also want them on object literals because of the clean declarative syntax they offer.

[Durisvk]

Is this even possible? I saw a discussion on Babel about this and they ended up with impossibility to implement decorators on function because of their hoisting.

Is hoisting acceptable in TypeScript? (I don't know because I've never used that)

[huan]

I beg, do not give up +1

[hax]

The standardization effort of function decorators has been moved to https://github.com/iddan/proposal-function-expression-decorators . The decorator of function declarations and the hoisting problem is discussed in No. 3 issue.

[OmgImAlexis]

Is there any news on this? Looks like nothing really changed in the last year or so.