3 ms·
I didn't miss it. I simply know projects that use UTF-8 for in-memory strings, and none of the ones I'm familiar with uses a different type for it. It's all c
by maxlybbert 12y ago
I didn't miss it. I simply know projects that use UTF-8 for in-memory strings, and none of the ones I'm familiar with uses a different type for it. It's all convention, and they all occasionally find that somebody flubbed the convention. Can you point me to any projects that manipulate UTF-8 encoded in-memory strings and actually use a different type for it them?
I realize I won't convince you. That's what I meant in the original comment that I know many people disagree with me on this.
- mpyne 12y ago> Can you point me to any projects that manipulate UTF-8 encoded in-memory strings and actually use a different type for it them? Glib seems to. https://developer.gnome.org/glib/2.37/glib-Strings.html https://developer.gnome.org/glib/2.37/glib-Strings.html Though in complete fairness the type appears to be just a "bags of bytes" type and so could hold anything, it's really meant to hold UTF-8 (as you can tell from the functions that append/prepend Unicode chars).
- maxlybbert 12y agoThanks for the pointer.
- masklinn 12y ago> I simply know projects that use UTF-8 for in-memory strings, and none of the ones I'm familiar with uses a different type for it. Which is relevant… how? > Can you point me to any projects that manipulate UTF-8 encoded in-memory strings and actually use a different type for it them? Rust does. Python 3.3 does something similar but slightly different (it switches internal representation between iso-8859-1, UCS2 and UCS4 depending on the string's codepoints). > I realize I won't convince you. That's what I meant in the original comment that I know many people disagree with me on this. Of course you won't convince me, your original comment is based on inane premises.
- maxlybbert 12y agoThanks for the pointers.