Numeric separator supported in implicit coercions, e.g., +"0_0"?

[littledan]

In the November TC39 meeting, IIRC @ajklein was asking if the Number constructor supported the _ separator. I believe Adam was trying to get at what happens in cases where ToNumber or the Number constructor are called, e.g., from unary +. @rwaldron answered that they are supported, but I don't see how that's done in the spec text--instead, the change in #16 seems to specifically ban _ (where it otherwise would've been allowed if the spec text remained unchanged). Is there something I'm misunderstanding here? Thanks to @anba for pointing out these semantics on a test262 thread.

[rwaldron]

The original thinking was that we could somehow specify Number("1_0") === 10 without adversely affecting the expected behavior of implicit coercions. Since then, we've decided that this creates too much web-breaking risk and we're going to limit NumericLiteralSeparator to only literals.

[littledan]

@rwaldron What is the web breaking risk? Is this documented somewhere?

Maybe I misunderstood the discussion in the meeting, but I thought the agreement in the committee was to keep the correspondence. If this changed, it might be worth it to give an FYI to TC39 to explain what happened and why.

[brn]

@littledan
I think this change cause web breaking because,
now Number('1_0_0') will become NaN, but If this separator introduced to a Number constructor,
this result will become 100.
So this breaks code that expected 1_0_0 will become NaN.
I think affected code is few, but not zero, so It's shouldn't introduced.
Coercions is basically naive problem, especially in javascript, we have many method for that and it's make things complicated.

[hax]

On the other side, If we let Number('1_0') and +'1_0' keep return NaN, is there any way the programmer can convert string '1_0' to 10 without filter _ manually?

[brn]

@hax
I have question that is there any reason to use separated-string-value?
Why use string value?

If we want to convert separated-string-value to number, there are some methods, but it's not realistic.

e.g.

function parseNumber(numberStr) {
  return Function(`return ${numberStr}`)();
}
const value = parseNumber("1_0_0");

value variable in above code will become 100.

But this example has big overhead,
so simple method that convert separated-string-value to number is currently not exists.

[hax]

is there any reason to use separated-string-value?

Who knows? 😆

...At least the js code analysis tools may need it. Anyway, it feels weird to not expose the same functionality of converting number literal to the programmers.

NOTE: Number('0b1') or +'0b1' return NaN in ES5, but 1 now. I'm not sure whether underscore should be treat differently.

[littledan]

I don't have a strong opinion here one way or the other about whether to support this; I just wanted to raise the issue that the current specification differs from my understanding of what was discussed in the January 2018 TC39 meeting between @rwaldron and @ajklein . As the feature is Stage 3 and implementation work is ongoing, I hope we can get this clarified soon from the champions.

[brn]

@hax @littledan
Anyway I implemented this cl in v8 without implicit coercions.
So I think its better to try it and rethink about it.

[rwaldron]

@littledan

Maybe I misunderstood the discussion in the meeting, but I thought the agreement in the committee was to keep the correspondence.

That was originally a goal, yes.

If this changed, it might be worth it to give an FYI to TC39 to explain what happened and why.

I fully intend to do this, but there hasn't been a meeting since the decision was made.

@brn

I think this change cause web breaking because, now Number('1_0_0') will become NaN, but If this separator introduced to a Number constructor, this result will become 100.

Correct. I had hoped that we could make this work without breaking the existing behaviour, but we could find no way and have decided that it's safer to make NLS apply only to literal syntax.

@littledan

I just wanted to raise the issue that the current specification differs from my understanding of what was discussed in the January 2018 TC39 meeting between @rwaldron and @ajklein

I explained the current status to @ajklein during a checkin that we had in February, according to my notes he was agreeable to the final design.

[littledan]

Is the web compatibility concern that now the semantics of Number will change, returning a Number for some arguments rather than NaN as it did previously? Or is there some more subtle web compatibility concern?