Re: [webidl] Numeric type reform strawperson (#33)

> So I would expect that the IDL browsers actually use would end up with just such annotations no matter what.

Yeah, that's fair, but it does feel like an implementation detail ... e.g. for a self-hosted implementation it wouldn't be useful.

In any case, it seems non-normative.

> 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

True. I did this basically because I wanted `number` to be the normal JS number type, not because of any informed thoughts about the common case. Maybe `fnumber` to make it convenient? `finite`? Or just abandon the attempt to conform to the JS type directly and let `number` be finite-enforced?

> The uses I see in Gecko's IDL in standard stuff are:

It seems to me all of these could be replaced by some unrestricted integer type. (The one I vaguely allude to with "We should almost certainly define a simple integer typedef. Unsure which is most idiomatic, but it should go up to 2^53 - 1.") That would be a change in behavior, and so likely not compatible (or at least not worth trying to change for so little gain). But I don't see anything in your arguments that implies the correct behavior for these parameters is to mod by 2^64 then potentially subtract 2^63 after flooring.

So indeed for cases like these I'd be happy for the specs to use `IntMod<18446744073709552000, 9223372036854776000>` or some typedef we define for it, either in WebIDL or in the relevant specs.

---
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/33#issuecomment-65850803