Ambiguity with numeric separators proposal

[not-an-aardvark]

How would the following be parsed when the numeric separators proposal is in effect?

const _5 = () => 5;

const num = 1234_5;

It seems like there would be an ambiguity between treating the _ as a separator for the value 12345, and treating it as the start of the identifier _5 as an extension of the literal 1234.

[littledan]

Good point. I think we could resolve this by simply disallowing certain identifiers. The previous proposal did something similar. What do you think?

[not-an-aardvark]

Disallowing some identifiers would resolve the ambiguity, although note that the problem is a bit bigger with hex literals:

const _beef = () => 0xbeef;

const num = 0xdead_beef;

So with the solution of disallowing certain identifiers, I think the proposal would have to disallow all identifiers that only contain the characters 0-9a-f and _ as literal extensions (optionally allowing identifiers with a trailing _, since there is no risk of ambiguity). This would probably only apply to a small percentage of identifiers, although it might be surprising when it does happen. (It could also create some edge cases when renaming variables or minifying, although they could be detected if the tool was aware of the edge case.)

[rwaldron]

Relevant:

• https://github.com/tc39/proposal-extended-numeric-literals/issues/8#issuecomment-361714521
• https://github.com/tc39/proposal-extended-numeric-literals/issues/8#issuecomment-361718942
• https://github.com/tc39/proposal-extended-numeric-literals/issues/2#issuecomment-361727987
• https://github.com/tc39/proposal-extended-numeric-literals/issues/2#issuecomment-361742150

[waldemarhorwat]

Disallowing all identifiers that only contain the characters 0-9a-fA-F and _ as literal extensions is insufficient to solve the problem. There are ambiguities even without those, which I'll leave here as an easy exercise for the reader.

[mathiasbynens]

There are ambiguities even without those, which I'll leave here as an easy exercise for the reader.

Could you please point out these ambiguities? Thanks.

[rbuckton]

While not ideal, you could use __id, since sequential underscores aren't permitted in numeric separators.

[littledan]

@rbuckton Yeah, that's a possibility that I put in the slide deck for the presentation last meeting that didn't happen. Another possibility is 1234$id, but that may be even uglier.

[gsathya]

It'd be great to come to a conclusion on this soon. Chrome and Firefox would like this to be resolved before shipping numeric separators.

[samuelgoto]

Hey all -- apologies for the delay here, but @rwaldron @leobalter @littledan and @samuelgoto met face to face and we think we have a recommendation to make.

We are hopeful that extensible numeric literals can either be worked out with a non-conflicting syntax and agreeable semantics (alternatives considered, TODO(goto): get the link to rick's analysis too), or otherwise, that they could be found to be unnecessary/unmotivated. For this reason, the numeric separators proposal champions (myself and rick) advocate to continue treating the use of _ as a stable Stage 3 proposal, making staging/shipping decisions appropriately based on individual implementation policies.

The numeric separator proposal champions plan to present this plan in more detail in the May 2018 TC39 meeting. In the meantime, we ask you all to hold implementation before we get some more validation.

We updated our explainer to reflect this position.

We know this isn't ideal from an implementation perspective, but we think that's a good balance between conservatism and pragmatism.

[samuelgoto]

Just an update:

• added the item to the agenda

https://github.com/tc39/agendas/pull/352

• update the text of the explainer to reflect the strategy

https://github.com/tc39/proposal-numeric-separator

[j-f1]

Why not use a space? i.e. 3 px desugars into px({ number: 3, string: "3" })

[samuelgoto]

Wouldn't that create some grammar ambiguity?

[j-f1]

How would that be ambiguous?

[tabatkins]

So this suggestion would basically make units into postfix unary keyword operators (and claim all the syntax space for such). Currently we only have prefix-unary and binary operators. I suspect that's okay?

[j-f1]

claim all the syntax space

Not quite — anything that’s not a valid identifier could become a valid postfix unary operator.

[tabatkins]

Thus my reference to "postfix unary keyword operators" ^_^

[j-f1]

OK, missed that.

[mathiasbynens]

Disallowing all identifiers that only contain the characters 0-9a-fA-F and _ as literal extensions is insufficient to solve the problem. There are ambiguities even without those, which I'll leave here as an easy exercise for the reader.

During today’s TC39 meeting, @waldemarhorwat gave the following examples: _0 and _0_px.

[gsathya]

The new decorators based syntax for extended numeric literals reached consensus at TC39, meaning, this proposal is no longer ambiguous with numeric separators.

[littledan]

Closing per https://github.com/tc39/proposal-extended-numeric-literals/issues/7#issuecomment-477650296