> Jerry Schulteis: 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.
You are correct. ------------------------------------------------------------- Intresting that cpp implements user literals as operators http://en.cppreference.com/w/cpp/language/user_literal I stuck with the idea that number "notation" and number "literals/postpositions" are the different things... So basicly if it is possible to say than number "literal/postposition"("user literal" or "user postposition" or whatever) SHOULD BE separated from the number by space - it resolves questions and allows to write e.g.: 1 min 1 sec 1n min 1uL whatever Moreover this also may work (it doesn't look good for me, but why not...): let minutesLeft = 5; let minutesLeftInMs = minutesLeft min; // or (minutesLeft)min This case preserves number suffix for number types and other goals and adding kind of generic syntax for "literals/postpositions" (which basicly are not required to be used with numbers, or return numbers) So the "literal/postposition" definition is just a simple function with single argument, which works with any type, e.g. function __literal_min(x) { // or __postposition_min return x * 60 * 1000; } Best regards, Andrey 2017-12-14 0:36 GMT+02:00 Jerry Schulteis <[email protected]>: > 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 <[email protected]> > 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
