Is it possible to allow a class decorator to return anything

[alamhubb]

Why must class decorators have a return value of T / void / undefined?

I need to implement such a function, not using decorators，Methods that return class instance objects

function ReturnObj(Constructor: Function) {
    return new Constructor()
}

class Test {
    name: string = 'name'
}


export default ReturnObj(Test)

This is too cumbersome to write, I want to use a decorator to implement it

function ReturnObj(Constructor: Function) {
    return new Constructor()
}

@ReturnObj
export default class Test {
    name: string = 'name'
}

Then I got an error, I looked up the relevant rules and found, microsoft/TypeScript#50820

Because I am a newbie to typescript, I can't think of the necessary reason for this design. I am curious about the original intention of this rule. Can you tell me?

In stage 2, any content is allowed to be returned, but it is not allowed in stage 3.

If it is still allowed, what problems will there be?

[pzuraq]

So the only real rule in the spec for the return value of a class decorator is that it must be constructable, e.g. you must be able to do new ReturnValue() to it. That does make what you want with just creating an instance tricky, but it would be doable with a Proxy for instance (since you can implement the constructor trap.)

The logic behind this is that decorators should not fundamentally change the "shape" of the value they are decorating. So, if a decorator is applied to a function, the result should be a function. If applied to a class, the result should be a class/new-able value. The reasoning is that if you were to come into a project with no outside knowledge at all, whatsoever, would you be able to have some idea of the constraints of what this decoration is doing?

Consider:

@foo
class Foo {
  @bar
  baz = 123;
}

If you do not know the definitions of @foo or @bar, what can you say about Foo? Currently, you can know the following:

// valid
const instance = new Foo();

// valid
instance.bar();

If we remove the restrictions, then you really can't say anything. Most of the time it would be valid, but sometimes it wouldn't. If you tried to do new Foo() and it didn't work, you might have to dig into a bunch of library code to figure out why. That breaks some amount of encapsulation.

There were also performance issues with allowing any return value, because the engine could no longer make assumptions about what the value would be, but I think those are secondary issues compared to the mental model and clarity that decorators have with these restrictions.