Sigbjorn, could you please file a WebIDL bug? Thanks. On Wed, Jan 8, 2014 at 8:24 AM, Mark S. Miller <erights@google.com> wrote: > Good catch. Yes, WebIDL apparently made the same mistake we had made at > first, not realizing why we need the narrower range. It should be changed > for the same reason we changed it in ES6. > > For those who missed the earlier discussion, the "desirable properties > wrt equational reasoning" that Sigbjorn refers to are, for example: > > var c = a + b; > if (isSafeInteger(a) && isSafeInteger(b) && isSafeInteger(c)) { > // c represents the accurate sum of a and b > } > > With the wider range, this guarantee is lost. > > > > On Tue, Jan 7, 2014 at 11:44 PM, Sigbjorn Finne <sof@opera.com> wrote: > >> Hi, >> >> currently, the ES binding for WebIDL uses the range of exactly >> representable integers [-2^53, 2^53] (*) >> >> http://heycam.github.io/webidl/#es-long-long >> http://heycam.github.io/webidl/#es-unsigned-long-long >> >> ES6 will provide support for testing the range of unambiguously >> representable integers [-2^53 + 1, 2^53 - 1] >> >> >> https://people.mozilla.org/~jorendorff/es6-draft.html#sec- >> number.issafeinteger >> >> a range with desirable properties wrt equational reasoning. >> >> So, with the above, if you have an attribute like >> >> [EnforceRange] attribute long long tvisyn; >> >> an implementation of the ES binding will enforce the WebIDL "long long" >> range, but ES(6) code will have to perform a second check of the range if >> concerned about restricting this to the safe range. >> >> How about aligning the WebIDL IDL range with ES6 & unambiguously >> representable integers? >> >> (Apologies if this has been resolved already or there's an open issue on >> it; couldn't find any.) >> >> --sigbjorn >> >> * - a fairly recent change, >> >> >> http://dev.w3.org/cvsweb/2006/webapi/WebIDL/v1.xml.diff?r1= >> 1.74;r2=1.75;f=h >> >> (it was the "safe" range prior to that.) >> >> >> > > > -- > Cheers, > --MarkM > -- Cheers, --MarkMReceived on Wednesday, 8 January 2014 16:26:01 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:19 UTC