Could mis-placed decorators be made to throw?

[ljharb]

Let's say I return an object from a decorator that has an initializer property, but the placement is not "field" - I'd like it to throw.

Similarly, if I return "private": true on a public property, I'd like it to throw.

In other words, the overarching desire is for a decorator intended for one placement, to throw, whenever possible, when it's used in the "wrong" placement.

[ljharb]

It would be even nicer if expected fields were type-checked; iow, if private is not undefined or a boolean, throw; if initializer is not undefined or a function, throw; etc.

[littledan]

Thanks for filing this bug; I will add something to make misplaced initializers throw. I'm not sure what you're referring to with "private"--that's not used right now. It's just part of the key.

[ljharb]

I'm definitely not aware of the entire API surface of what can be returned; that's part of why I want it to throw when I do something wrong :-)

[littledan]

One point about evolution in the future here: In theory, it could cause compatibility issues if we add more fields, to check for those and throw on them. We might just be able to do this the first time. Or, we might risk that compat possibility anyway.

[ljharb]

Changing things from "throws" to "does something" has generally been considered a web-compatible change; but you're right that someone could potentially rely on the exception.

[littledan]

I was saying, for example, we could make a field do something for class decorators, and then we'd want to make it throw an error if you use it on field decorators, but throwing there could cause a compatibility issue.

[littledan]

See https://github.com/tc39/proposal-decorators/pull/30 for that strictness.

[littledan]

Fixed by https://github.com/tc39/proposal-decorators/pull/30 .