Decorator support in instance functions

[normalser]

class Test {

    // works
    @f()
    test() {

    }

   // does not work
    @f()
    test2 = ()=> {
    }

}

It would be useful if decorator would work in second case

[Thinkscape]

This is a major pain point. The latter is seen by the compiler as a property, hence property decorator rules apply - the decorator function doesn't receive a PropertyDescriptor. Even though a property decorator can return a descriptor, it can not access the original/intended value (the bound function).

From docs:

NOTE  A Property Descriptor is not provided as an argument to a property decorator due to how property decorators are initialized in TypeScript. This is because there is currently no mechanism to describe an instance property when defining members of a prototype, and no way to observe or modify the initializer for a property. As such, a property decorator can only be used to observe that a property of a specific name has been declared for a class.

I think there should be an easy way to receive the value inside the decorator, so it can be manipulated - otherwise decorators are unusable in above context (bound methods).

[RyanCavanaugh]

@rbuckton is this a duplicate of something?

[mhegazy]

The semantics of these two declarations is significantly different.

Methods (e.g. test) are created at class declaration time, and are placed on the prototype. Properties (e.g. test2) are initialized in the constructor for every instance, and live on the object itself.

Decorators do not run for every object, they only run on the declaration of the class. since the initialization expression can have side effects, it can not be evaluated at the declaration time, but rather has to be initialized in every invocation of the constructor.

This change will need some concept of "initializer" function that is part of the PropertyDiscriptor that would be passed in the decorator, but for that we need to wait for both decorators and public fields