4 ms·
> utf-8 as it should be Agreed, but now your standard library doesn't have string support, it has byte buffer support. That's no improvement over C, compared t
by maccard 6y ago
> utf-8 as it should be
Agreed, but now your standard library doesn't have string support, it has byte buffer support. That's no improvement over C, compared to rust.
- flohofwoe 6y agoThe downside of a single string type built into the standard library or even into the language is that it needs to be both flexible and performant, and in my experience, those two things exclude each other (e.g. how do you append two high-level strings like "str1 + str2" without hidden allocation?). Apart from that, Zig's string processing functions are not that bad, what's unexpected is that they are in the memory-operations part of the standard library, not in a specific "string module" (after all, the Zig compiler is (being) written in Zig, and the parser needs to do a lot of string-munching, so I guess we'll get more powerful string processing helper functions in the standard library over time). But if I need to do lots of high-level string processing I probably wouldn't chose a systems programming language to begin with, languages like Python are a better match for this.
- lhorie 6y agoZig does have utf8 APIs, though to be fair, the docs are quite sparse
- m45t3r 6y agoThe fact that they're not NULL terminated and the slices itself have length information is already a great improvement over C.