4 ms·

> I've always tried as much as possible to treat strings as just opaque data and never look into them, which tends to work well, but in some domains you really

> I've always tried as much as possible to treat strings as just opaque data and never look into them, which tends to work well, but in some domains you really need to look at and massage the characters/codepoints/grapheme clusters, and the lack of a first-citizen UTF-8-aware string type is, I think, a bit unfortunate in this day and age. You don't need a string type for that, you just need routines that handle UTF-8 strings, like utfcpp (https://github.com/nemtrif/utfcpp https://github.com/nemtrif/utfcpp).

moogly 5y ago
Sure, you're not wrong. For my purposes that'd work, but I'm of the opinion that delegating that to an optional library will make a lot of developers lazy and not even bother thinking about Unicode/i18n/l10n issues at all. I've seen so much code, in a multitude of languages that is oblivious to it, but even if it's reified in a type or even having some form of language support, I guess you can argue that people can still ignore it.
- mikepurvis 5y ago
  That was basically the state of affairs with strings in Python 2, and although the transition was awful, I'm really, really appreciative of Python 3 now having clearly-separated str and bytes types.
- moogly 5y ago
  In addition, I should add there are synergy effects in having the community (and the major libraries) settling on a common way, and you'll only really get that if there is a built-in. However, if the philosophy here is to be unopinionated and optimize for flexibility over everything else, I feel I can't really fault them for making that choice.
kristoff_it 5y ago
Agreed, and Zig also has a lib for that as well: https://github.com/jecolon/ziglyph/ https://github.com/jecolon/ziglyph/
- moogly 5y ago
  Ooh, haven't come across this. Thanks!
- coldtea 5y ago
  If it's not a single official library, then this will just end up in a future mess... Like in any language with any lib that is not self-contained (cuts across all aspects of a program and can be used anywhere) and has many different implementations and no sanctioned one.

moogly 5y ago

Sure, you're not wrong. For my purposes that'd work, but I'm of the opinion that delegating that to an optional library will make a lot of developers lazy and not even bother thinking about Unicode/i18n/l10n issues at all. I've seen so much code, in a multitude of languages that is oblivious to it, but even if it's reified in a type or even having some form of language support, I guess you can argue that people can still ignore it.

mikepurvis 5y ago
That was basically the state of affairs with strings in Python 2, and although the transition was awful, I'm really, really appreciative of Python 3 now having clearly-separated str and bytes types.
moogly 5y ago
In addition, I should add there are synergy effects in having the community (and the major libraries) settling on a common way, and you'll only really get that if there is a built-in. However, if the philosophy here is to be unopinionated and optimize for flexibility over everything else, I feel I can't really fault them for making that choice.

kristoff_it 5y ago

Agreed, and Zig also has a lib for that as well: https://github.com/jecolon/ziglyph/ https://github.com/jecolon/ziglyph/

moogly 5y ago
Ooh, haven't come across this. Thanks!
coldtea 5y ago
If it's not a single official library, then this will just end up in a future mess... Like in any language with any lib that is not self-contained (cuts across all aspects of a program and can be used anywhere) and has many different implementations and no sanctioned one.