On 6/15/20 12:07 PM, Hubert Tong wrote:
> On Mon, Jun 15, 2020 at 11:49 AM Tom Honermann <tom_at_[hidden]
> <mailto: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]
>> <mailto: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.

Ah, I think I missed the indication that existing practice was to map to
the C1 control characters. Thanks for the correction.

Tom.