[Jasper_]

It is possible to specify new APIs that say "UTF-8 only, if you pass an unpaired surrogate, you will get an error", and many such APIs already behave that way. They are, on the whole, not a major problem in practice. They are not not fundamentally incompatible with JavaScript/Java/Dart/Kotlin/C# -- it just means that if you wish to call an API that only accepts UTF-8, you must make sure your inputs are valid UTF-8 -- the only lossy case is for invalid Unicode strings, likely generated by accident. It is not dishonest to want to add APIs that behave that way.

It's fine to disagree with me or the committee, but your grand gesturing and your overstatements about how tightening a single bolt on strings will break web compatibility forever is exhausting to listen to, especially when you claim large-scale political conspiracy and use words like "fundamentally incompatible with JavaScript". I don't see any of it.

Your behavior in those threads are absurd, unnecessary, and alarmist, and I really don't have any sympathy for you. Even this reply doubles down on the over-exaggeration.

I think large parts of WebAssembly are mismanaged. I have major complaints about the velocity, instability, and web APIs, I spend a lot of time in them, I'm grumpy, and I'm not usually one to go to bat for any of this. Even within the WebAssembly/JavaScript/WASI interop, there are 20 things I'd put on the list ahead of this. If I have any advice for you, it's to pick a new battle, because this is maybe this is the highest complaint to lowest impact ratio I've ever seen. You lost, just move on.

[dcode]

Allow me to focus on the technical arguments, that I think fall short. Sure, one can go and make a second string type, or a bunch of throwing APIs. I'd question that this actually improves a language in a tangible way, or that anyone would want that for a rational reason that is not induced from the outside. When not doing so, it's incompatible in the sense of the word. Whether incompatibility isn't much of a deal depends, I guess. For someone not having a respective use case, perhaps, but for someone else having exactly that use case, say hashing substrings to then discover unexpected collisions, or streaming 1K chunks of strings over component boundaries, then discovering mojibake after concatenating, it might very well be significant, or even expensive. I mean, there are good reasons all those languages try the best they can to prevent that in their native habitats. What amazes me is that all that came to be because someone has formulated a desire, that could easily be fulfilled in addition with a boolean flag for W/UTF, but refuses to include such a trivial compromise, which surprisingly has more weight than any evidence, or precedents like WebIDL, JSON, or the various language standards. I find this highly concerning, since it conflicts with my understanding of responsible engineering. Also conflicts with Wasm's communication, that literally states that Wasm executes in the same semantic universe as JavaScript, and maintains backwards-compatibility with the Web. Perhaps, if there is something fruitful to spin a narrative around, then that these decisions undermine the exact value proposition of AssemblyScript, that was supposed to be used in tandem/closely with JavaScript, which now becomes risky on the fundamental level of the most prominent higher-level data type, strings. Plus, of course, when two AssemblyScript components communicate. That makes these string decisions particularly unfortunate for me personally after having spent all that time and effort, working towards Wasm's goals in good faith, perhaps explaining my persistence on the matter. Quite a dilemma.

[Jasper_]

Sure, there are technical arguments for this approach, but there are also technical arguments for "the strings in our strings API should really be valid Unicode strings". I have no horse in this race and I have no preference, but I do see both options as completely valid.

The problem is when you say things like people that prefer the latter approach "can only be either dishonest, or incompetent". Putting it kindly, you're basically only making enemies at that point, and you seem unwilling to consider other points of view, at best. You seem absolutely baffled about why your tone, phrasing, and language are making others uncomfortable, even as you continue to insult those you're trying to influence.

I have never met you before this conversation, and I came away with a very negative impression. There are reasons you aren't being listened to, and they are problems with you and your behavior, not grand conspiracies.

There are battles worth staking your entire professional reputation over -- the GC repo is full of people doing that -- but this is definitely not one of them.

[dcode]

Well, I tried. Anyway, even if I was the abhorrent monster you keep painting in your almost exclusively ad hominem argumentation while accusing me of what you are undoubtedly guilty of yourself, I'd argue that none of this justifies plain ignoring technical concerns in a standardization effort. This exchange is an almost perfect reflection of the practices prevalent in the Wasm CG, that made the Component Model, and likely other things elsewhere, possible almost uncontested. And surely this is deliberate abuse, and I hope people can see that. And coincidentally, that's exactly my critique. I hope nobody is surprised that being at the receiving end of this, despite your best efforts, for years, is an extraordinarily frustrating experience, and that this is exactly the point.