Repository navigation
Issue an error when numeric literals can incur precision loss #29863
Description
Activity
- changed the title
[-]Error when numeric literals can incur floating point precision loss[/-][+]Issue an error when numeric literals can incur floating point precision loss[/+]on Feb 11, 2019 - changed the title
[-]Issue an error when numeric literals can incur floating point precision loss[/-][+]Issue an error when numeric literals can incur precision loss[/+]on Feb 11, 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.
Reacted by Titian Cernicova-DragomirWe don't have warnings - just errors 😄🔥🌎🔥😄
Reacted by Titian Cernicova-Dragomir, Andrii Dieiev and Trotyl YuReacted by Jordan Harband and Karan SharmaWhich behavior will be accepted?
- numerical compare to bigint literal
- numerical literal compare to bitint literal
- numerical literal compare to bigint
- numerical literal compare to bigint literal
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
0x6A09E667F3BCC908withThis numeric literal's value is too large to be represented accurately as an integer.I don't necessarily think we'd want the error for any numeric literal with a fractional component (e.g. no error on
9000000000000000000000000000.000000009).This numeric literal's value is too large to be represented accurately as an integer.This is nice, but most don't know that 253 is the maximum for these. Perhaps a friendly error message would be something like:
Numeric literal values equal to 2^53 or greater are too large to be represented accurately as an integer.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.
How about a quick fix to add an
nto the end of the numeric literal, if possible?Feel free to add a quick fix to insert the bigint suffix.
Reacted by Josh Ghoulberg 👻Feels like this is better off as some sort of lint rule. 😢
Thanks for the PR though Josh Ghoulberg 👻 (@JoshuaKGoldberg).
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.)
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.
In JavaScript, you can write out a really really big (non-
bigint) integer literal and get a completely different value.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))