search

tc39 / proposal-class-fields

Orthogonally-informed combination of public and private fields proposals
https://arai-a.github.io/ecma262-compare/?pr=1668
1.72k stars 113 forks source link

Explicit spec text forbidding # shorthand? #137

Closed ljharb closed 5 years ago

ljharb commented 6 years ago

My understanding of the goal of removing the shorthand was to allow for the future possibility of adding it later.

If this is the case, should this proposal's spec add it to Forbidden Extensions, so that we can ensure the syntax is reserved for our future use?

(Separately, the explicit forbidding of the shorthand would be necessary for test262 tests, per https://github.com/tc39/test262/pull/1782)

littledan commented 6 years ago

I'm not sure what it means to add this to the forbidden extensions when we're explicitly considering an extension that would include it. Overall, I don't understand what that section is for. I'd like to pursue this in a broader discussion in TC39 about what the grammar means exactly.

ljharb commented 6 years ago

It would be preventing an implementation from extending it, until we decided to include it.

littledan commented 6 years ago

I'm not sure what that really means. For example, what status would Babel implementations be in, and how does this relate to other extensions which are not explicitly forbidden but also in Babel? I don't understand the purpose of these metaphysical distinctions; I'd prefer that JS just be as well-defined as possible.

ljharb commented 6 years ago

In the same way as the spec currently forbids "the token : to immediately follow source text that matches the BindingIdentifier nonterminal symbol", yet both TypeScript and Flow do it via babel, willfully violating the spec here, we'd add a well-defined item to that list that forbids the # token from appearing except immediately after a ..

I'm not sure why this is "metaphysical" nor not well-defined; as you stated here:

(unless you count TypeScript or proposals to add to JS, but IMO these are different sorts of things)

ie, like Babel, and:

We know from experience that actually taking advantage of implementation-specific extensions is bad for compatibility

The intention would be to ensure nobody implements shorthand syntax before we're able to come to consensus on doing so.

littledan commented 6 years ago

Well, I think that's a bit different--we're not planning on adding this : syntax to JS, whereas we are considering adding private shorthand (and even if we add this as a forbidden extension, there will be other proposals which are not forbidden extensions). The high-level thing is, I don't think we should need to add text into the main specification to justify writing tests or just because we're thinking about another proposal or things like that.

bakkot commented 6 years ago

I think the "forbidden extensions" thing only really makes sense in the historical context of browsers experimenting with language extensions without consulting with each other or the broader community (e.g.). Since they don't seem to be inclined to do that sort of thing anymore (thankfully), I don't think we necessarily need to worry about people shipping a syntax before we have consensus on it.

Personally I'd be happiest if we could add a "everything not permitted is forbidden" part to the spec, but that might be hard to get through & would require some careful wording to allow browsers to ship stage 3 proposals (since the current spec makes no reference to the proposal process at all).

littledan commented 5 years ago

Let's pursue this question in https://github.com/tc39/ecma262/issues/1323 .