On Mon, Jun 15, 2020 at 11:49 AM Tom Honermann <firstname.lastname@example.org> wrote:
On 6/15/20 4:18 AM, Corentin Jabot wrote:
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).
- 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
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.