Unless I badly misunderstood Andrey's post he does not want something like
numeric separators, that get ignored by the VM; he wants 1M to translate (I
presume at compile time) to 1_000_000 (here's hoping numeric separators makes
it into the spec) and 3min to translate to 18_000.
While I see some merit to the idea, I think adding such things to the language
ad hoc leads to PHP--not the direction I'd like to see JavaScript take. I think
any proposed addition to a language should be reviewed as to whether it
constitutes a specific case of some more general principle.
Moreover, the BigInt proposal is at Stage 3 and would use an "n" suffix to
indicate a BigInt literal; the Extensible Numeric Literals proposal is at Stage
1 and would make further use of the same syntactic space ("i" for imaginary
numbers, "m" for decimals); Brendan Eich's Int64 slide deck
(https://www.slideshare.net/BrendanEich/int64) uses "L" as suffix for Int64,
"uL" for Uint64, and considers extending the concept to user-defined value
types. If such user-defined value types ever make it into JavaScript, it might
give Andrey something close to what he wants.
On Tuesday, December 12, 2017, 1:16:02 PM CST, Sam Goto <g...@chromium.org>
wrote:
+ rick that co-authored numeric separators too and may have thoughts on this.
my first impression is that this (if kept purely as something that gets ignored
by the VMs) shares a lot of the sentiments with numeric separators ....
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
