Zig solved this by not having a string type at all and not shipping full Unicode support in std: https://github.com/ziglang/zig/issues/234#issuecomment-27630....

That attitude as described feels like chucking a large portion of the benefit you get from leaving C out the window.

But...

> But at that point, why does it need to be part of the language? Would not a standard library module suffice?

This indicates zig is desired to ship with unicode support—just not part of the core language runtime. Now this I can support—unicode doesn't require core runtime support. Most programs don't have a need for unicode text normalization, for instance, so why would you need this without linking in a standard library? But the idea of not shipping unicode in your standard library rightfully died decades ago.

Notably, this doesn't imply:

* source code being ascii

* string literals being ascii

* unicode string processing not being immediately available in the standard environment

So I'm not sure which behavior is being described here, but I certainly consider utf8 support to be table-stakes for language design in 2025. Without this a language is a toy. I'm not going back to using ICU and will fight anyone who encourages me to.

I will consider the issue.