Suggestion

🔍 Search Terms

decorators, decorators normative changes

✅ Viability Checklist

My suggestion meets these guidelines:

• [?] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

This does change behaviour, but given this is a spec change TypeScript should be doing so regardless.

⭐ Suggestion

This is a spec change in the decorators proposal. TypeScript should implement these changes.

Changes

Of the changes, only static accessors and natural this in decorators are behaviour that will have to change. The other changes were either not implemented by TypeScript (SetFunctionName), spec bugs (HomeObject stuff), or the new behaviour is already implemented by TypeScript (addInitializer throws on non-function).

For natural this in decorators the following should not type error, and in down-leveling should not cause the assertion to fail either (playground link):

function assert(cond: boolean): asserts cond {
    if (!cond) {
        throw new Error(`assertion failed`);
    }
}

class DecoratorProvider {
    #x = 3;

    decorate<T>(this: this, v: T, ctx: DecoratorContext): T {
        // This assertion should not fail in down-leveled code
        assert(this !== undefined);
        return v;
    }
}

const instance = new DecoratorProvider();

class Foo {
    // Should not be a type error
    @instance.decorate
    method() {

    }
}

For static accessors this should succeed at runtime in down-leveling, the typing is already correct (playground link):

class A {
    static accessor x = 3;
}

class B extends A {}

// Currently throws when down-leveled, but should succeed
console.log(B.x);