About IDL's string enums

Hey folks,

I had a brief chat with Brad Nelson (cc'd) (WASM chair) last week about
string enums. Here's my summary (Brad: if you wouldn't mind, correct me if
I've misrepresented anything).

* Probably possible (though difficult) to make them somewhat fast (~as fast
as JS is now), and likely to be valuable for other Web APIs too.
* BUT: it may be hard to make them fast enough to rely on them in the
critical path of the API (e.g. draw call). I investigated this a bit more:

Taking a look at Blink code for some APIs that use IDL enums (like WebAudio
and 2D Canvas), I determined, at least, that these entry points are not
doing anything special when they take in IDL enums: They just receive a C++
string object, and convert to a C++ enum via a helper function that does
string comparisons.
(It's possible that string enum comparisons are fast in JITed JS (e.g.
webapi.getThing() == "variant2"), but they are not currently fast going out
to native code.)

If I'm understanding correctly, solving this problem (just for JS) would
require a whole new concept to be added throughout the stack - from the JS
engine (V8) API to the bindings code to Blink - to be able to recompile
string enums from the app's JS source into some kind of integer ID that can
be compared efficiently in Blink. (Blink would have to be able to query
this integer ID from the V8 VM as well.)

And that's ignoring WebAssembly. For WebAssembly, we would need some way
for it to - at load time - either (a) like Blink, query the integer ID for
a given string, or (b) create a table from i32s to strings which, when used
in Host Bindings, are guaranteed to get efficiently turned into the integer
IDs on the way into Blink.

All in all, this looks like a huge project, and I definitely feel we cannot
rely on it when designing an API for WebGPU (all assuming I'm not missing
something important).