New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
littledan opened this Issue Dec 6, 2017 · 10 comments

Comments

Projects
None yet
4 participants
@littledan
Member

littledan commented Dec 6, 2017

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

This comment has been minimized.

Contributor

rwaldron commented Jan 29, 2018

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

This comment has been minimized.

Member

littledan commented Jan 31, 2018

@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

This comment has been minimized.

brn commented Feb 28, 2018

@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

This comment has been minimized.

hax commented Feb 28, 2018

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

This comment has been minimized.

brn commented Feb 28, 2018

@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

This comment has been minimized.

hax commented Feb 28, 2018

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

This comment has been minimized.

Member

littledan commented Feb 28, 2018

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

This comment has been minimized.

brn commented Mar 8, 2018

@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

This comment has been minimized.

Contributor

rwaldron commented Mar 8, 2018

@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.

@rwaldron rwaldron closed this Mar 8, 2018

@littledan

This comment has been minimized.

Member

littledan commented Mar 8, 2018

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment