On 4/26/22 4:12 PM, Jens Maurer via SG16 wrote:
> On 26/04/2022 22.06, Tom Honermann via SG16 wrote:
>> The summary for the SG16 meeting held April 13th, 2022 is now available. For those that attended, please review and suggest corrections.
>>
>> * https://github.com/sg16-unicode/sg16-meetings#april-13th-2022
>>
>> No decisions were made at this meeting.
>>
>> I again apologize for being so delinquent getting the summary published.
>>
>> Jens, I fear I misunderstood or incorrectly captured some of your comments. Please see the editor's note starting with "This behavior doesn't seem related to the proposed change since ...". If you recall the discussion being different than I wrote, I'll update it to reflect your recollection.
> I think you should just strike all of this:
>
> Jens stated that this makes such intended use in identifiers ill-formed since, after this change, such a character would appear as a lone preprocessing-token.
> [ Editor's note: This behavior doesn't seem related to the proposed change since, previously, a UCN naming one of these characters would also appear as a lone preprocessing-token. The editor is concerned that this portion of the discussion was not captured accurately. ]
Done, thank you!
>
> I think there was some development during the discussion
> about the current and future state with these new
> characters. Having an updated paper clearly stating
> the current and with-paper situations would be helpful.
Agreed, I suspect Steve intends to provide that.
Tom.
That's what I'm planning. The complicated bit is the implications for the "C" locale, although it's not an issue for the "POSIX" locale, although I don't think it's a real world concern these days that the default encoded character set doesn't have what POSIX calls the portable character set. Tracing the requirements is tedious because C++ defers to C, which in turn defers to the ISO version of the POSIX specification for much of the locale machinery.
Paper soon.