You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 17, 2022. It is now read-only.
Repository navigation
This repository was archived by the owner on Aug 17, 2022. It is now read-only.
That's a good question. So as background, I think it's important to have wasm-to-Web-IDL calls be mostly equivalent to wasm-to-JS-to-Web-IDL calls, where the interposed JS simply forwards arguments/results back and forth to Web IDL -- that way, if a built-in Web IDL function is polyfilled/virtualized by JS, it doesn't suddenly break wasm. While (list u8) would be the most natural match for ByteString, passing a (list u8) to JS would produce a Uint8Array, and the ECMAScript ByteString coercion won't accept a Uint8Array. But I think you're right that string isn't a good match either.
Thinking about it some more, it seems like there are three options:
extend Web IDL so that ByteString accepts a Uint8Array
add a new abbreviationbytestring ≡ (list u8) that matches ByteString and that the JS API would coerce into a JS string
punt, saying ByteString only matches externref, requiring wasm to create ByteStrings with a separate import call
I think 1 would be ideal, and perhaps it would be beneficial for other reasons. WDYT?
I see, if it has to be mostly equivalent it will have to be a string, as that is what it is in JavaScript. I suppose IDL could accept a Uint8Array on the coercion side, but it couldn't start returning Uint8Array where it previously returned a string. (Unless there is some magic that would enable this for Wasm callers only?)
(I was mainly suggesting this because I think it makes sense for IDL to convert this string to a byte sequence for specifications and to allow specifications to return a byte sequence to something that wants a ByteString. Whether this makes sense to copy in implementations would vary, but for HTTP header related cases it definitely would.)
Ah, good point about the return case, I forgot to consider that. Because of the "allow interposed JS" goal I mentioned above, I don't think we can use "if the caller is wasm ..." logic. However, I think we could say that ToWebAssemblyValue(v, (list u8)) accepts JS strings in v (in addition to the obvious cases, like arrays) by performing a Web IDL JS-to-ByteString conversion which throws if any element of the string is >255.
Activity
lukewagner commentedon Mar 17, 2021
That's a good question. So as background, I think it's important to have wasm-to-Web-IDL calls be mostly equivalent to wasm-to-JS-to-Web-IDL calls, where the interposed JS simply forwards arguments/results back and forth to Web IDL -- that way, if a built-in Web IDL function is polyfilled/virtualized by JS, it doesn't suddenly break wasm. While
(list u8)would be the most natural match forByteString, passing a(list u8)to JS would produce aUint8Array, and the ECMAScriptByteStringcoercion won't accept aUint8Array. But I think you're right thatstringisn't a good match either.Thinking about it some more, it seems like there are three options:
ByteStringaccepts aUint8Arraybytestring ≡ (list u8)that matchesByteStringand that the JS API would coerce into a JS stringByteStringonly matchesexternref, requiring wasm to createByteStrings with a separate import callI think 1 would be ideal, and perhaps it would be beneficial for other reasons. WDYT?
annevk commentedon Mar 17, 2021
I see, if it has to be mostly equivalent it will have to be a string, as that is what it is in JavaScript. I suppose IDL could accept a Uint8Array on the coercion side, but it couldn't start returning Uint8Array where it previously returned a string. (Unless there is some magic that would enable this for Wasm callers only?)
(I was mainly suggesting this because I think it makes sense for IDL to convert this string to a byte sequence for specifications and to allow specifications to return a byte sequence to something that wants a ByteString. Whether this makes sense to copy in implementations would vary, but for HTTP header related cases it definitely would.)
lukewagner commentedon Mar 18, 2021
Ah, good point about the return case, I forgot to consider that. Because of the "allow interposed JS" goal I mentioned above, I don't think we can use "if the caller is wasm ..." logic. However, I think we could say that
ToWebAssemblyValue(v, (list u8))accepts JS strings inv(in addition to the obvious cases, like arrays) by performing a Web IDL JS-to-ByteString conversion which throws if any element of the string is >255.