Use Web IDL, while preserving our goals

[domenic]

Especially as I work on #6, I become increasingly convinced that we should use Web IDL to specify KV storage. There's too much by-hand crap going on. Especially once whatwg/webidl#580 happens, which could replace a ton of the by-hand crap I'm doing for #6.

The current spec discusses why it doesn't use Web IDL in https://wicg.github.io/kv-storage/#class-definition-explanation. To overcome those objections, and get feature parity with the post-#6 spec, we'd need to add the following capabilities to Web IDL:

• A switch that toggles on same-realm-only brand checks
• The ability to expose values in modules
• Async iterators, including:
  • The ability to alias [Symbol.asyncIterator] to entries()
  • The ability to include the same-realm-only brand check on a class's async iterator
  • Parity with the spec I'm writing for Should keys/values/entries be async iterators? #6, which seems like it would be hard to do generically with a "yield this value" framework as discussed in Async iterators whatwg/webidl#580.
• Optionally, but ideally, the ability to have non-enumerable methods

I consider this blocked on those Web IDL improvements, but I know @littledan was looking into those sorts of things anyway. And I wanted to log this to record my intention, and update the spec to point to this issue.

[littledan]

Thanks for this clear description of what's needed; this is really helpful. I think my teammate @Ms2ger will be available sooner than me to work through these issues.

[littledan]

We probably also need to figure out what the equivalent of the WebIDL [SecureContext] extended attribute does for built-in modules, whether we want the module to be missing from the module map or to throw an error during execution. My intuition is the former, but this specification draft has the latter, though this is a minor point.

@domenic and I discussed this offline; it would be fine with me to make this tweak and other small changes for WebIDL conversion over time. The experience with a post-initial-ship WebIDL conversion for the WebAssembly JS API went OK (even if it wasn't exactly fun or prompt).

[Ms2ger]

Looking into this.

[domenic]

I'll note that since the OP, @jakearchibald gave some sample code that may allow me to rewrite the spec for KV storage's async iterator in a "yield this value" style. So we should probably go with that style.

[littledan]

@domenic Does that mean we should prioritize whatwg/webidl#580 then?

[domenic]

Well, that's the only one of the three that @Ms2ger hasn't already created pull requests for :). So yeah, that'd be good. It's also one that I think has no open design questions, so it should be easier in that sense. (Harder in terms of spec text to write, though.)