On Wed, Aug 10, 2022 at 3:01 AM Hubert Tong via Liaison <
liaison_at_[hidden]> wrote:

> On Tue, Aug 9, 2022 at 11:00 AM Aaron Ballman via Liaison <
> liaison_at_[hidden]> wrote:
>
>> Our next meeting will be on Mon Aug 15, 2022 at 15:00 UTC
>> (
>> https://www.timeanddate.com/worldclock/converter.html?iso=20220815T150000&p1=tz_pt&p2=tz_mt&p3=tz_ct&p4=tz_et&p5=1440
>> ).
>>
>> You can join the meeting at https://iso.zoom.us/j/5513145100
>>
>> P1854R3 (https://wg21.link/p1854r3) Conversion to execution encoding
>> should not lead to loss of meaning
>> Proposes to make non-encodable values in character and string literals
>> ill-formed (a constraint violation, in C parlance). The author is
>> looking for feedback on whether WG14 would be likely to want to see a
>> similar proposal, as well as feedback on whether the approach in the
>> paper is tractable for shared headers.
>>
>> P2320R0 (https://wg21.link/p2620r0) Lifting artificial restrictions on
>> unviversal character names
>> Proposes to relax a restriction that a universal character name cannot
>> be used in place of a character in the basic character set, which is a
>> restriction that C has but C++ does not. The author is looking for
>> feedback on any concerns people have with unifying the behavior in
>> both languages to match the C++ behavior.
>>
>
> It is not clear whether this paper suggests that keywords may be spelled
> with UCNs and the paper is also missing consideration for user-defined
> literals.
>

I am certainly *not* proposing that UCNs should be allowed in more places
than they currently are.
So keywords can not be spelled with ucn, and users defined literal can.
Nothing changes.

The paper argues that within UCNs, limiting to non-basic character sets
does not have any value or motivation and it's just one more special case
that code generators may have to handle, for example.
I never found UCNs for identifiers to be very well motivated to begin with,
but if we are going to have them, we should not special case some
characters on the basis that UCNs are even less useful for them.

I do not believe the wording is clear that UCNs cannot be used to form UCNs.
>

What do you mean? (Please not that there is a new version of the paper
which make the wording clearer https://isocpp.org/files/papers/P2620R1.pdf )


>
> I am not convinced that using UCNs for Basic Latin characters is
> well-motivated (the fact that using UCNs for non-Basic Latin characters may
> be helpful does not automatically mean that it is a good idea for Basic
> Latin).
>

I'm not trying to argue that it would be helpful (except that we do have
reports of code generators wanting to use that), just that it is neither
more, or less useful, and that the distinction of basic vs non-basic in
UCNs is
artificial and opinionated.


>
>
>>
>> P2621R0 (https://wg21.link/p2621r0) UB? In my lexer?
>> Proposes to change a semantic restriction on line splicing which forms
>> a universal character name, which is currently undefined behavior. The
>> paper proposes to either define that behavior or make it ill-formed,
>> because the notion of undefined compile-time behavior is unclear to
>> users and does not appear to provide any benefit for implementation
>> extensions in this case.
>>
>
> I think this paper is an opportunity to urge compilers to have options of
> producing preprocessed output with transformations to/from UCNs (with a
> choice of output encoding).
>
>
>> _______________________________________________
>> Liaison mailing list
>> Liaison_at_[hidden]
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
>> Searchable archives: http://lists.isocpp.org/liaison/2022/08/index.php
>>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2022/08/1108.php
>