Am So., 16. Aug. 2020 um 12:40 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > My thoughts exactly. Allowing any non-ASCII character is liable to cause confusion at best and actively mislead at worst as to what bytes are actually in the bytevector, even if a standardized encoding were chosen.
>
> Strongly agreed.
>
> Even if we stay in the Latin-* (i.e. ISO-8859-*) range, different
> Unicode normalization forms will encode some of those characters
> differently. One would have to inspect the byte-level encoding of the
> Scheme source file from which a particular literal is read in order to
> figure out the bytes. A source file can also be re-encoded from say
> Latin-1 to UTF-8 which would again change the byte-level encoding while
> the display in a text editor keeps looking identical.

I think the main reason is that if we allowed the full Unicode range
and specified UTF-8 encoding, sequences like \x80; would be ambiguous.
Either the byte 80 is meant or the bytes corresponding to the UTF-8
encoding of U+0080.

In order to allow implementations to extend #u8"..." so that "..." can
be any string allowed by the implementation (*), I want to suggest to
rename the sequence "\xHH;" of this SRFI into something different like
"\yHH;". I think this is a good thing because "\xHH;" in strings and
characters really means something different for bytes greater than
#x7F as soon as we encode it in UTF-8 (which string->utf8 does).

--

(*) In other words, we should at least allow implementations to extend
SRFI 207 so that if "..." is any string literal, u8"..." is equal to
(string->utf8 "...").