Reminder, this meeting is happening in a little over three hours from
now. Hope to see you there!

~Aaron

On Tue, Aug 9, 2022 at 11:00 AM Aaron Ballman
<compatibility.sg.chair_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.
>
> 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.