4 ms·

Given the nature of it (pretty.c) and the stated intention of being "backwards-compatible with C and all of its libraries", what would make more sense than stic

Given the nature of it (pretty.c) and the stated intention of being "backwards-compatible with C and all of its libraries", what would make more sense than sticking with C's multibyte strings? https://en.cppreference.com/w/c/string/multibyte https://en.cppreference.com/w/c/string/multibyte

IgorPartola 2y ago
Right but pretty.c doesn’t seem to explicitly support those.
- michaelsbradley 2y ago
  How so? it’s just char*
  - IgorPartola 2y ago
    What if len() of a char* vs a Unicode string?
    - michaelsbradley 2y ago
      char* is just raw bytes. At the language level C historically hasn't offered much support for working with specific character sets and their encodings. With C17 and C23 we get u"...", U"...", u8"...", type char8_t, and similar, but there's still little/no built-in tooling for text processing. For text processing work with char* whose bytes are some encoding/s of Unicode, e.g. UTF-8, then you an use a C library such as libunistring or ICU. However the bytes of a char* could instead be an encoding of a non-Unicode character set, e.g. GB2312 encoded as EUC-CN. So char* is character set and encoding agnostic. And C-the-language doesn't even try to offer you tools for working with different sets and encodings. Instead, you can use a library or write your own code for that purpose. A number of languages make the same decision, keeping the string type set/encoding agnostic, with libraries taking up the slack. In Nim, for example, the string type is essentially raw bytes (string literals in .nim sources are UTF-8). If you're doing Unicode text processing then you'd use facilities from the std/unicode module https://nim-lang.org/docs/unicode.html https://nim-lang.org/docs/unicode.html Same story with Zig https://ziglang.org/documentation/0.8.0/std/#std;unicode https://ziglang.org/documentation/0.8.0/std/#std;unicode Lua too, and you'll probably use a 3rd party library such as luaut8 for working with Unicode/UTF-8 https://github.com/starwing/luautf8 https://github.com/starwing/luautf8 Returning to the matter of pretty.c, since it's just sugar for C, it makes sense (to me) that the string type is just an alias for the set/encoding agnostic char*. It's up to the programmer to know and decide what the bytes represent and choose a library accordingly.

IgorPartola 2y ago

Right but pretty.c doesn’t seem to explicitly support those.

michaelsbradley 2y ago
How so? it’s just char*
- IgorPartola 2y ago
  What if len() of a char* vs a Unicode string?
  - michaelsbradley 2y ago
    char* is just raw bytes. At the language level C historically hasn't offered much support for working with specific character sets and their encodings. With C17 and C23 we get u"...", U"...", u8"...", type char8_t, and similar, but there's still little/no built-in tooling for text processing. For text processing work with char* whose bytes are some encoding/s of Unicode, e.g. UTF-8, then you an use a C library such as libunistring or ICU. However the bytes of a char* could instead be an encoding of a non-Unicode character set, e.g. GB2312 encoded as EUC-CN. So char* is character set and encoding agnostic. And C-the-language doesn't even try to offer you tools for working with different sets and encodings. Instead, you can use a library or write your own code for that purpose. A number of languages make the same decision, keeping the string type set/encoding agnostic, with libraries taking up the slack. In Nim, for example, the string type is essentially raw bytes (string literals in .nim sources are UTF-8). If you're doing Unicode text processing then you'd use facilities from the std/unicode module https://nim-lang.org/docs/unicode.html https://nim-lang.org/docs/unicode.html Same story with Zig https://ziglang.org/documentation/0.8.0/std/#std;unicode https://ziglang.org/documentation/0.8.0/std/#std;unicode Lua too, and you'll probably use a 3rd party library such as luaut8 for working with Unicode/UTF-8 https://github.com/starwing/luautf8 https://github.com/starwing/luautf8 Returning to the matter of pretty.c, since it's just sugar for C, it makes sense (to me) that the string type is just an alias for the set/encoding agnostic char*. It's up to the programmer to know and decide what the bytes represent and choose a library accordingly.