Re: [heycam/webidl] BREAKING: Convert the `unrestricted` keyword into an extended attribute (#857)

I tried to come up with some things I value in IDL that I think largely overlap with prior points made here:

* Types in implementations. If a systems language might want a different type, I think that's a good hint for IDL. (This might argue for splitting ArrayBuffer and SharedArrayBuffer, though not sure about typed arrays. It also defends the current decisions around strings.)
* Clarity and readability. For example, I think the current `float` fails here a bit as the size is not clear and more importantly it's not clear that it's very different from other languages (by not accepting infinity and not-a-number). `float32` and `restricted-float64` (I'm not sure about restricted, but also not sure about basic/numeric alternatives) seem preferable. IDL is read a lot, the clearer it is at a glance what will happen the better.
* Alignment with type terminology of Infra, JavaScript, and WebAssembly. (DOMString -> String or even string?) And also alignment with type terminology from other languages to the extent possible.
* Ease-of-use. Common things should be straightforward. I think in specifications we also get a lot of easy-of-use through "automatic" mapping between IDL types and Infra. We haven't quite figured out what the story for numbers should be there, but Infra should probably not have as many types as IDL. (I'm thinking "floats" and "integers" for prose and the IDL boundary takes care of conversion.)

In the end some of these decisions will have to be tradeoffs, but as long as try to maximize the benefit for these different audiences we'll be fine I think.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/857#issuecomment-617869340