On Mon, Jun 15, 2020 at 11:49 AM Tom Honermann <tom_at_[hidden]> wrote:

> On 6/15/20 4:18 AM, Corentin Jabot wrote:
>
>
> On Mon, Jun 15, 2020, 08:40 Tom Honermann <tom_at_[hidden]> wrote:
>
>
>> 1. It enables an escape from Unicode should such an escape prove
>> necessary (e.g., to support those EBCDIC control characters, or to encode
>> whether a UCN was explicit in the source or the result of character
>> conversion, or to encode which of the possible Shift-JIS code points a
>> character was written in). Yes, such an escape could always be introduced
>> anyway. And yes, these are edge cases, some of which are probably not
>> deserving of support.
>>
>>
> The standard is explicit about there not being any observable difference
> outside of raw literal
>
> Yes, and Hubert has claimed that the existing wording is deficient in this
> area because it doesn't reflect existing practice (e.g., those EBCDIC
> control characters).
>
I believe I said that the existing wording does not clearly consider the
situation of the EBCDIC control characters. It also does not provide much
space for a design choice of differentiating between EBCDIC control
characters and C1 control characters. I did, however, indicate existing
practice is in line with performing the conversion to the UCS codespace.