whatwg
draft: Interaction with the Stage 2 Record & Tuple proposal for ECMAScript
Hello, this draft PR is a prototype spec text that attempts to define a minimal interaction between the Record & Tuple proposal for ECMAScript and WebIDL. The proposal is currently at Stage 2 so there is no intent to merge this PR at the moment but the goal is to open a conversation for our approach here.
In this PR, we want to keep things minimal: we do not intend just yet to add Record & Tuple to WebIDL types, we are only defining a conversion algorithm when records are put in place of objects (option bags notably) and when tuples are similarly put in place of arrays...
If the need arises later to have an API defined with WebIDL that return a Record or a Tuple for instance, then more work would be needed...
- [ ] At least two implementers are interested (and none opposed):
- …
- …
- [ ] Tests are written and can be reviewed and commented upon at:
- …
- [ ] Implementation bugs are filed:
- Chrome: …
- Firefox: …
- Safari: …
- Deno: …
- Node.js: …
- webidl2.js: …
- widlparser: …
(See WHATWG Working Mode: Changes for more details.)
I should normally have been cleared for participation by Bloomberg that should have signed the agreement.
Hey @rricard, Participation data looks correct. It'll be marked verified once this is ready to land. We usually do that jointly with the first contribution. I've also ensured Build runs.
Excellent thank you for checking this! We'll clear that out then once it is ready to land which is not the case yet...
I notice the record<K, V> conversion isn’t changed here yet. That’s probably just because it’s a work in progress, but it would be funny if we couldn’t use em for that, so I figured it may be worth pointing out just in case it was overlooked.
let headers = new Headers(#{ "content-type": "record/record; record=record" });
As with dictionary member types, the V type of record<K,V> might not be compatible with the primitive-members-only nature of ES Record/Tuple. In practice I’m pretty sure most usages are a natural match, though. From the first few pages of matches for record<K,V> usage in specs, most of them had V in the string/number/tuple-of-the-same zone:
(sequence<sequence<ByteString>> or record<ByteString, ByteString>)
record<DOMString, sequence<DOMString>>
record<DOMString, double>
record<USVString, double>
record<USVString, (USVString or undefined)>
record<USVString, (USVString or sequence<USVString>)>
record<DOMString, GPUSize64> // GPUSize64 = unsigned long long
Another missing conversion is any. This one seems important because adding a new ES language type would cause it to have undefined behavior. The defined behavior could be to throw a TypeError if the goal is to be conservative pending a clearer picture of what’s needed.
Union conversion and the overload resolution algorithms are affected similarly I think.
(You’ll notice the former still hasn’t sorted stuff out from the last new language type! e.g. (symbol or DOMString) is allegedly valid, but the conversion algorithm can never actually succeed for a Symbol value.)
That’s probably just because it’s a work in progress, but it would be funny if we couldn’t use em for that, so I figured it may be worth pointing out just in case it was overlooked.
Another missing conversion is
any. This one seems important because adding a new ES language type would cause it to have undefined behavior.
Thank you for this, I definitely overlooked both, will try to add them soon!