- From: Boris Zbarsky <notifications@github.com>
- Date: Fri, 05 Dec 2014 11:56:50 -0800
- To: heycam/webidl <webidl@noreply.github.com>
- Message-ID: <heycam/webidl/issues/33/65845297@github.com>
> declaring a return type as an unsigned long is meaningless Not entirely. With my browser implementor hat on, annotating a return type with a restricted integer range allows the JIT to optimize based on that information. So I would expect that the IDL browsers actually use would end up with just such annotations no matter what. > A new number type, along with a [EnforceFinite] extended attribute One imporant question is whether EnforceFinite should be opt-in or opt-out. Right now it's opt-out. You're proposing making it opt-in, but in practice as far as I can tell the common case is specifications not wanting to deal with non-finite numbers. > My hope is that e.g. long long is used infrequently and mistakenly, The uses I see in Gecko's IDL in standard stuff are: 1) Blob.slice, for start and end args. The idea is to allow slicing from the end by passing negative values and to allow blobs larger than 4GB, hence "long long". 2) File.lastModified. This has to be long long to not run out in a few years and needs to be signed because the Unix epoch is just not that long ago. 3) In typedef form GLIntptr and GLsizeiptr are all over WebGL; these represent offsets within possibly-large buffers. 4) GLint64 in WebGL2, for timeout values. --- Reply to this email directly or view it on GitHub: https://github.com/heycam/webidl/issues/33#issuecomment-65845297
Received on Friday, 5 December 2014 19:57:17 UTC