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 do not believe the wording is clear that UCNs cannot be used to form UCNs.

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).


>
> 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
>