Re: Ada 202x; 2022; and 2012 and Unicode package (UTF-nn encodings handling)

[Alex // nytpu <nytpu@example.invalid>]

On 9/2/25 12:08 PM, Dmitry A. Kazakov wrote:
> The matter is quite straightforward:
Objectively false, "text" is never actually straightforward despite what 
it seems like on a surface level :P
> 1. Never ever use Wide and Wide_Wide. There is a marginal case of 
> Windows API where you need Wide_String for UTF-16 encoding. Otherwise, 
> use cases are absent. No text processing algorithms require code point 
> access.
Somewhat inclined to agree with Wide_<> but I don't see strong 
justification to *never* use Wide_Wide_<>, there's pretty substantial 
tradeoffs to both using UTF-32 and UTF-8 (in any programming language 
that supports both, but particularly with Ada's string situation) so 
unfortunately it ultimately falls on the programmer to understand and 
choose.
> 2. Use Character as octet. String as UTF-8 encoded.
Perfectly valid, explicitly mentioned as an option in my post.  Maybe 
actually would be better for most applications because they wouldn't 
need to transcode it, I should've noted that more clearly in my original 
response.  The only two issues: make sure to avoid the Latin-1 String 
routines unless you know you're doing is sound; and in older Ada 
versions I remember reading long debates about the String type may not 
be able to safely store UTF-8 on many compilers (of the era), but that 
issue was clarified by even Ada 95 IIRC.

I just personally prefer Wide_Wide_<> to get its slightly more 
Unicode-aware string routines, but it's not the only (or even inherently 
the best) option.

~nytpu

-- 
Alex // nytpu
https://nytpu.com/ - gemini://nytpu.com/ - gopher://nytpu.com/