On 04/07/2022 8:16 AM, Ola Fosheim Grøstad wrote:
On Sunday, 3 July 2022 at 19:32:56 UTC, rikki cattermole wrote:
It is required for string equivalent comparisons (which is what you
should be doing in a LOT more cases! Anything user provided when
compared should be normalized first.
Well, I think it is reasonable for a protocol to require that the input
is NFC, and just check it and reject it or call out to an external
library to convert it into NFC.
Anyway, UTF-8 is the only format that isn't affected by network byte
order… So if you support more than UTF-8 then you have to support UTF-8,
UTF16-LE, UTF16-BE, UTF-32LE, UTF-32BE…
That is five formats for just a simple string… and only UTF-8 will be
well tested by users. :-/
https://issues.dlang.org/show_bug.cgi?id=23186
We only support UTF-16/UTF-32 for the target endian.
Text input comes from many sources, stdin, files and say the windowing
system are three common sources that do not make any such guarantees.
