[Feature request] Don't introduce new tokens about proposal-decorators

[littledan]

Thanks for your input here. I like that you are writing in with ideas for what would be good for JS as a whole--we need input from lots of JS programmers there, not just TC39 members.

My biggest concern with an existing token is ASI. If we use an existing token, users may be forced to use a semicolon before a decorated class declaraction when they wouldn't need one for an undecorated class declaration.

Secondarily, a new token can be especially evocative. You can make an association that @ means decorator. Overloading existing tokens makes this harder.

@ljharb previously proposed swapping @ and #. The committee did not accept the proposal at the time largely because many programmers are happy with @ in transpilers. Presumably, those programmers would not be so excited to switch to / or ^ either.

[ljharb]

Template literals were added which use backticks, which are brand new tokens - your inference is incorrect; there's no resistance to adding new tokens nor any preference to prefer existing ones.

[ljharb]

I’m confused; why would it be better to use a token with an existing meaning, rather than a new one?

@ljharb It seems that introducing new symbols (characters) for new functionality is something which is generaly discouraged in EcmaScript. Let's take a look at few examples. When generator functions as methods of object literal are introduced, their token was * (they didn't use # or @, or Џ, or any illegal tokens, they used existing tokens which was illegal in that context until generator functions have been introduced). Another example: spread operator. They might use # for spread operator, but no, they decided to use three consecutive dots, which had been illegal until that proposal. There are a lot more examples, like ([a])=>a, or (a=b)=>a, or tagged template literals, or similar. It seems that using old symbols with new meaning is prefered over introducing new symbols.

Symbols # and @ were never a valid JavaScript tokens, and I don't see a reason to make them valid after this proposal. In my opinion, it would be much better to use, for example, & and ^ respectively, as these tokens are currently invalid in such context. But, anyways, this is just my opinion, I suggested, but you decide.

It seems like the community really likes the proposed tokens @ and #. Do you think it would be good to close this feature request, or which procedure is usually used in such situations? I mean, do we organize some poll or something similar, or, when the situation is clear (like in this case) we close feature request immediately?

It really isn't much important to me, I just thought that there was some sort of hindrance from introducing new tokens, but as explained above, there was not, so I think it would be good to decide what the community says.

Feel free to close this if you want.

Closing. This feature request would not be accepted by the community, as explained above.

[ljharb]

Do you have any reasoning for yourself to prefer reusing an existing token, however? TC39 can worry about what's generally encouraged or discouraged in EcmaScript :-)

There's no resistance to adding new tokens nor any preference to prefer existing ones.

Okay, if that is true.

Do you have any reasoning for yourself to prefer reusing an existing token?

Few reasons:

1. The code looks more familiar to JavaScript. If we continue introducing new symbols in every new ES version, we will end up using all unicode characters as keywords or operators.
2. Code highlighters and editors will not be forced to deal with extra new tokens. Just a bit of modifying old tokens in special contexts (where these tokens were not allowe din previous version) will solve the problem.
3. Similarly for JavaScript parsers and code beautifiers and obfuscators

TC39 can worry about what's generally encouraged or discouraged in EcmaScript.

I agree. Basically, I suggested, but TC39 will decide is it good or bad.

[ljharb]

Regarding code highlighters and editors (and parsers and beautifiers and obfuscators), it's the same change to highlight a new token, or to change their parsing of an old token - any grammar change forces these things to adapt.

As for "looks more familiar", imo that's a reason to use a new symbol - it's not a good thing if it looks familiar but doesn't do something familiar.