There's no point of making this disingenuous strawman argument. The fact is that JavaScript has legacy, broken strings and hasn't been fixed to support what Unicode has been for the past 21 years. JavaScript can be easily fixed rather than propagating brokenness further.
Conversation
I agree that a new language inspired by JavaScript can have really unicode-aware operations for all the remaining USC2 methods. But changing the format from UTF16/WTF16 to UTF8 would cause a complete change in string API. Even Dart couldn't do that.
1
JavaScript strings are not UTF-16 or Unicode strings. Every UTF-16 string can be represented as UTF-8. If JavaScript had UTF-16 strings, there would never be one you couldn't convert to UTF-8.
UTF-8 is what's used for input/output and JavaScript is already forcing conversions.
1
Dart made the mistake of supporting compiling to JavaScript and heavily orienting itself around that ecosystem. I don't see why WebAssembly should inherit JavaScript's flaws rather than JavaScript being improved to support proper interoperability with nearly everything else.
1
I want to emphasize that nobody forces Wasm to support only UTF16. The point is that Wasm or more precisely Interface Types, which is an external layer, should also understand UTF16 along with UTF8, so that IT can be effectively used not only by Rust/Go, but also by Java, JS, C#
1
JavaScript strings aren't UTF-16. JavaScript is perfectly capable of supporting actual UTF-16 or supporting much more sensible UTF-8 strings. WTF-16 is not UTF-16 and doesn't belong in new languages / environments.
JavaScript strings are arrays of 16-bit integers, not Unicode.
2
WebAssembly has support for arrays of 16-bit integers and it can be turned into UTF-8 with the programmer deciding how to deal with the invalid Unicode such as by using replacement characters.
JavaScript strings can't simply be turned into UTF-16 strings without error handling.
2
Anything not using UTF-8 should just be converted to UTF-8 in the earliest possible place. The way to improve performance is converting fully to UTF-8. UTF-8 is the universal encoding used for everything. JavaScript could have used it from the beginning and chose not to do it.
1
No point in having UTF-16 across the boundary instead of converting to UTF-8 before sending it across. Anything reasonable is going to be using UTF-8 on the other side. If it's not, it should be fixed. Using anything else is not a mistake that should be propagated further.
1
You've demonstrated in this thread that UTF-16 is extremely harmful beyond inefficiency due to all the broken APIs treating it as UCS2 and people wrongly thinking that it works like UCS2 or that they can get away with it. Lots of broken nonsense in lots of software from this.