On 9/10/22 10:33 AM, Corentin Jabot via SG16 wrote:
>
>
> On Sat, Sep 10, 2022 at 3:47 PM Tom Honermann via SG16
> <sg16_at_[hidden]> wrote:
>
> SG16 will hold a telecon on Wednesday, September 14th, at 19:30
> UTC (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20220914T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
>
> The agenda is:
>
> * Report on the on-going interactions between WG21 and the
> Unicode Consortium.
> * Report on the backward compatibility impact of P1949 (C++
> Identifier Syntax using Unicode Standard Annex 31)
> <https://wg21.link/p1949>.
> * Continued discussion of P2626R0: charN_t incremental adoption:
> Casting pointers of UTF character types
> <https://wg21.link/p2626r0>.
>
> SG16 has previously engaged with the Unicode Message Format
> Working Group (MFWG)
> <https://github.com/unicode-org/message-format-wg> (in our March
> 11th, 2020 telecon
> <https://github.com/sg16-unicode/sg16-meetings/blob/master/README-2020.md#march-11th-2020>)
> and the Unicode Source Code Ad Hoc Group (SCAHG) (in our May 25th,
> 2022 telecon
> <https://github.com/sg16-unicode/sg16-meetings#may-25th-2022> with
> Robin Leroy). Peter and Tom have continued engaging with these
> groups. Tom will report on their activities (Peter is not expected
> to be available for this meeting).
>
> Implementation of P1949 in Clang (as a DR unconditionally applied
> to older language modes) prompted some users to report substantial
> impact to projects that previously enjoyed use of mathematical
> symbols in identifiers. Tom will report on some specifics of the
> impact, discussion between Clang implementors, and on-going work
> by the SCAHG that may provide a solution in the future. Further
> discussion should focus on guidance that we may want to offer to
> implementors.
>
> To clarify, it impacted substantially a very small number of users.
> The DR status is somewhat beside the point as these users have
> communicated that it is not desirable for them to be stuck on C++20
> forever.
>
> Pending Corentin's availability, we'll continue discussion of
> P2626R0 from our August 24th, 2022 telecon
> <https://github.com/sg16-unicode/sg16-meetings#august-24th-2022>.
>
> I do believe there are core level concerns to be resolved, the main
> ones being
>
> * Can we specify that destroying a range of charX through a pointer of
> range of charY is well defined - as we have established that the
> interface is not usable in common cases if there needs to be a
> restoring conversion prior to destruction. This is the main issue
> * Can we control the effect on parent objects (it would be reasonable
> that any access to an object be undefined while one of the subobjects
> is casted to a different type, but once the cast is reverted, the
> object needs to be usable again).

A third one is:

* Is an implementation required to detect access to an object by the
wrong type as UB during constant evaluation? For example:

    constexpr char test() {
       char8_t c8a[] = u8"text";
       char *cp = cast_utf_to<char>(c8a);
       c8a[0]; // Ok? Or UB?
       c8a[0] = 'X'; // Ok? Or UB?
       return cp[0]; // Ok? Or UB because an object of char8_t type
    was written there?
    }
    constexpr char g = test();
    static_assert(g == 'X'); // Ok? If so, this implies aliasing awareness.
    static_assert(g == 't'); // Ok? If so, this implies distinct objects
    in overlapping regions of storage.

Corentin's prototype implementation doesn't diagnose UB in this example
and accepts the first static_assert (and fails the second).

Tom.

>
>
> Tom.
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
>