On 2018-03-18 21:53, Mike Samuel wrote:
For good or for worse, my proposal is indeed about leveraging ES6's take on JSON including limitations, {bugs}, and all. I'm not backing from that position because then things get way more complex and probably never even happen.Extending [*] the range of "Number" is pretty much (in practical terms) the same thing as changing JSON itself. Your proposal is limiting Number; my alternative is not extending Number.
Quoting earlier messages from you: "Your proposal is less interoperable because you are quoting a SHOULD, interpreting it as MUST and saying inputs MUST fit into an IEEE 754 double without loss of precision. This makes it strictly less interoperable than a proposal that does not have that constraint" "JSON does not have numeric precision limits. There are plenty of systems that use JSON that never involve JavaScript and which pack int64s" Well, it took a while figuring this out. No harm done. Nobody died. I think we can safely put this thread to rest now; you want to fix a problem that was fixed > 10Y+ back through other measures [*]. Thanx, Anders *] Cryptography using JSON exchange integers that are 256 bit long and more Business system using JSON exchange long decimal numbers Scientific systems cramming 80-bit IEEE-754 into "Number" may exist but then we are probably talking about research projects using forked/home-grown JSON software "Number" was never sufficient and will (IMO MUST) remain in its crippled form, at least if we stick to mainstream. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
