Repository navigation
Issue an error when numeric literals can incur precision loss #29863
Description
In JavaScript, you can write out a really really big (non-bigint) integer literal and get a completely different value.
0x6A09E667F3BCC908n == 0x6A09E667F3BCC908n // true
0x6A09E667F3BCC908n == 0x6A09E667F3BCC908 // false!?
It's worth asking whether or not a really really big integer values which have different observed and specified values are erroneous, and whether we can give users an error.
This would be a breaking change, but it's not clear who benefits from the current behavior.
See tc39/proposal-bigint#170 for where this came up (CC Daniel Ehrenberg (@littledan))
Activity
[-]Error when numeric literals can incur floating point precision loss[/-][+]Issue an error when numeric literals can incur floating point precision loss[/+][-]Issue an error when numeric literals can incur floating point precision loss[/-][+]Issue an error when numeric literals can incur precision loss[/+]littledan commentedon Feb 12, 2019
This is a great idea! However, this behavior been part of JS forever, so it might be good to start with a warning and see how it goes.
DanielRosenwasser commentedon Feb 12, 2019
We don't have warnings - just errors 😄🔥🌎🔥😄
Kingwl commentedon May 16, 2019
Which behavior will be accepted?
DanielRosenwasser commentedon May 16, 2019
It's actually not about the comparisons themselves - it's about writing out an integer numeric literal whose value is too large to be represented accurately. In this specific case, I think we'd expect to error on a number like
0x6A09E667F3BCC908withI don't necessarily think we'd want the error for any numeric literal with a fractional component (e.g. no error on
9000000000000000000000000000.000000009).JoshuaKGoldberg commentedon Sep 3, 2019
This is nice, but most don't know that 253 is the maximum for these. Perhaps a friendly error message would be something like:
JoshuaKGoldberg commentedon Sep 3, 2019
How about a quick fix to add an
nto the end of the numeric literal, if possible?DanielRosenwasser commentedon Sep 3, 2019
Feel free to add a quick fix to insert the bigint suffix.
DanielRosenwasser commentedon Sep 3, 2019
Feels like this is better off as some sort of lint rule. 😢
Thanks for the PR though Josh Ghoulberg 👻 (@JoshuaKGoldberg).
fatcerberus commentedon Sep 7, 2019
IMO if I write out a numeric literal in the source text and assign it to a variable, without manipulating it in any way, and then observe a different value at runtime, I would wonder why the compiler didn’t yell at me (after spending probably several minutes debugging it :P)
Only literals which can be exactly represented should be accepted.
(Note that a codefix to change large numbers to bigint isn’t necessarily safe - mixing them with regular numbers in operations will produce runtime errors.)
fatcerberus commentedon Sep 7, 2019
Then again,
1.1can’t be exactly represented in IEEE double either so it then becomes a question of how much precision loss you want to accept. Hmm.Also huge numbers like
1e100would likely be errors too since it’s unlikely they won’t be rounded... nevermind, I take it back, this is a terrible idea. 😛I agree with Daniel Rosenwasser (@DanielRosenwasser), this is a job for a lint tool, not the compiler.