We've been over this, see my recent post which linked to older ones.
We're not *switching* the spec's "Number" type (typeof x == "number") to
IEEE 754r DFP. The hardware's not there, and the differences will break
graphics and other such apps.
We're also not inclined to hardcode just a decimal addition.
Dave's new strawman hardcodes the types people need -- especially
Node.js hackers, but also anyone using typed arrays => binary data. And
as he pointed out we can extend ES7 to enable user-defined value objects
with extensible operators and literals, and remap the hardcodings Dave
proposes as built-ins using the same extension mechanism.
This looks winning to me. The Node and Binary Data use-cases are upon us
and they're valid.
/be
Herby Vojčík wrote:
Hm, I feel a bit conservative... I think having single number type has
its pluses.
I'd only include bignum and added MAX_INT (and probably
LIMIT_INT_POWER2 and LIMIT_INT_POWER10) to Number. If there is a
chance that IEEE754r will be good enough to adopt in next five years,
I'd just update Number to be 128bit and so MAX_INT gets higher as well
as LIMIT_INT_POWER2 (that goes well beyond 64) and LIMIT_INT_POWER10,
so they will have their int64 and uint64 there.
I understand lots of apps want "native" int64 as soon as possible, but
I do not like "uint64" etc. "types" - they are too technical, there
are lots of them, one then must check what conversions are safe ...
whatever.
Dave
Herby
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
