Extended attributes vs. new types

Hi Boris (cc public-script-coord for future reference),

I'm looking at tackling the shared array buffer + Web IDL issues discussed in https://www.w3.org/Bugs/Public/show_bug.cgi?id=29388 and related threads, and would appreciate some extra help walking me through the problems with extended attributes and union types you allude to in https://bugzilla.mozilla.org/show_bug.cgi?id=1231687#c17 (and which have motivated things like USVString in the past). I know you explained it briefly there, but I'm still a little lost, and feel that I need to get a solid grip on the issue if I'm to be productive here. So a more extensive explanation would be really appreciated.

Here are some questions whose answers might help me:

What exact steps would go wrong in the spec if we used [AllowShared] Uint8Array, or [EnsureUTF16] DOMString, instead of MaybeSharedUint8Array/USVString? What are the problematic Web IDL snippets, JS inputs, and spec steps that we end up at?

Why is this different than things like [Clamp] or [EnforceRange]? The way that they insert themselves into the JS -> Web IDL conversion steps seems totally reasonable to me. Does [Clamp] also break down when trying to use it with union types?

What spec surgery would be involved in fixing this whole situation? I guess the idea would be to make the extended attributes apply to the types instead of the arguments, but how exactly would that help?

Thanks!
-Domenic

Received on Wednesday, 11 January 2017 23:12:32 UTC