Requiem for a stringref
I really have trouble understanding the push to provide higher-level features as intrinsic types and instructions.  AIUI, the main alternative to stringref (linked in the article: <a href="https:&#x2F;&#x2F;github.com&#x2F;WebAssembly&#x2F;js-string-builtins&#x2F;blob&#x2F;main&#x2F;proposals&#x2F;js-string-builtins&#x2F;Overview.md">https:&#x2F;&#x2F;github.com&#x2F;WebAssembly&#x2F;js-string-builtins&#x2F;blob&#x2F;main&#x2F;...</a>) is to provide string types via WebAssembly&#x27;s normal &quot;import&quot; mechanism.  This alternative makes more sense to me.<p>When you write extension modules for languages like Python, Ruby, PHP, or even JavaScript (via V8 or JavaScriptCore), you are always importing APIs like strings (eg. #include &lt;ruby.h&gt;).  It seems natural to me that WebAssembly would be the same way.<p>Now ideally a WebAssembly module wouldn&#x27;t be specific to one particular embedding environment.  You would want to standardize this string API, so that a single API can be used efficiently with multiple host languages.  So you&#x27;d want something more like #include &lt;wasm&#x2F;wtf16string.h&gt;.  But if it&#x27;s an import, it also leaves open the possibility that such an API can evolve over time, or that a competing API could supplant it as the landscape of language engines changes.  By putting it directly into the instruction set, you&#x27;d be baking in assumptions about how JS engines in 2023 function, even though those assumptions can (and hopefully will) change over time.<p>It&#x27;s true that wasm&#x2F;wtf16string.h probably won&#x27;t be available in environments that don&#x27;t have JS-style strings.  But that seems for the best.  I&#x27;d rather have a leaner WebAssembly than make every WebAssembly engine provide JS-style strings.  In the case that the host environment doesn&#x27;t already have a JS-style string that you are trying to interoperate with, why not just have Java implement its string type directly in WebAssembly?  Or once shared libraries are available, wasm&#x2F;wtf16string.h could be provided via some third-party library, shared across multiple modules, leaving open the possibility of passing strings around between modules.<p>I guess, to the article&#x27;s point, why <i>shouldn&#x27;t</i> memcpy() be an import also?  What is gained by making it part of the instruction set?  I assume that a WebAssembly implementation could recognize special imports, and optimize them the same as if it were a built-in instruction.