Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

draft: Interaction with the Stage 2 Record & Tuple proposal for ECMAScript #1184

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

rricard
Copy link

@rricard rricard commented Aug 23, 2022

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.)


Preview | Diff

@rricard
Copy link
Author

rricard commented Aug 23, 2022

I should normally have been cleared for participation by Bloomberg that should have signed the agreement.

@annevk
Copy link
Member

annevk commented Aug 24, 2022

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.

@rricard
Copy link
Author

rricard commented Aug 24, 2022

Excellent thank you for checking this! We'll clear that out then once it is ready to land which is not the case yet...

@bathos
Copy link
Contributor

bathos commented Sep 17, 2022

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

@bathos
Copy link
Contributor

bathos commented Sep 17, 2022

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.)

@rricard
Copy link
Author

rricard commented Sep 20, 2022

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants