W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2014

[Bug 24241] Adopt the ES6 "safe integer" range for (unsigned) long longs

From: <bugzilla@jessica.w3.org>
Date: Thu, 09 Jan 2014 04:44:06 +0000
To: public-script-coord@w3.org
Message-ID: <bug-24241-3890-yHUVcUjmoV@http.www.w3.org/Bugs/Public/>

--- Comment #6 from Boris Zbarsky <bzbarsky@mit.edu> ---
> What's offensive is that we pretend this behavior has something to do with
> traditional C-ish concepts of float, double, short, long, long long, etc

Well, it does, in actual browser implementations right now...  It's not so much

> or that the variables are actually "typed" that way, when of course they're
> all just `Number` in JS.

I think that depends on what you mean by "typed", and I think it's worth
thinking of incoming and outgoing values separately.

Incoming values aren't even "Number" in JS, really; they're just arbitrary
values.  If you pass { valueOf: function() { return Math.random() * 1000; } }
to an IDL method labeled as taking "long" no one will stop you.  Of course it
might be faster to pass in actual Number values.  But it might also be faster
to pass in integer-valued Numbers than it is to pass in Numbers with a nonzero
fractional part!  I agree that for incoming values we may want a richer set of
constraint/behavior annotations than WebIDL provides now, by the way, so that
spec algorithms can just assume their inputs are sane based on the IDL and get
on with the bits they really care about.

For outgoing values, on the other hand, at least SpiderMonkey actually uses
information like "this DOM method always returns an integer that we can
losslessly represent as a 32-bit machine integer" to perform certain JIT
optimizations, and I hope to do more of that sort of thing in the future (e.g
feeding more information to range analysis).  While of course such
optimizations can be attempted based on some sort of dynamic guards, it sure
helps when you statically know something about value ranges.  Again, it might
help to have annotations about the _actual_ range of values here, not just the
current size labels, but it's a lot harder to make the case that spec writers
should care about annotations like this that in fact do not affect observable
behavior...  Right now picking which particular numeric type to return from a
method is somewhat a waste of the spec writer's time, since they really do all
en up as Number in the end, conceptually.  Except that given JITs, they _don't_
actually all end up as IEEE doubles in practice.

You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 9 January 2014 04:44:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:19 UTC