This is your friendly reminder that this meeting is happening today, in
about two hours.

Tom.

On 2/3/25 5:25 PM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a meeting on Wednesday, February 5th, at 19:30 UTC
> (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20250205T193000&p1=1440&p2=tz_pst&p3=tz_mst&p4=tz_cst&p5=tz_est&p6=tz_cet>).
>
> If you need a .ics file to import into your calendar, you can download
> it here
> <https://documents.isocpp.org/remote.php/dav/public-calendars/R7imgS2LJD9xfeWN/B2C540AF-83F3-42DA-B74A-283F0F31306D.ics?export>.
>
> The agenda follows.
>
> * P3560R0: Error Handling in Reflection <https://wg21.link/p3560r0>.
> * P2758R4: Emitting messages at compile time
> <https://wg21.link/p2758r4>.
>
> P3560R0 proposes changing how errors encountered during reflection
> operations are handled. P2996R9 (Reflection for C++26)
> <https://wg21.link/p2996r9> currently specifies that a reflection
> error results in the expression not being a core constant expression;
> see the "/Constant When/" requirements in the wording. The adoption of
> P3068R6 (Allowing exception throwing in constant-evaluation)
> <https://wg21.link/p3068r6> created the opportunity to use standard
> C++ exceptions for error reporting during constant evaluation and
> P3560R0 advocates for switching to an exception handling model. The
> proposed std::meta::exception class differs from std::exception in
> that it is not polymorphic, its member functions are declared
> consteval, and, most significantly for SG16. its constructor and
> what() member function take and return std::u8string_view
> respectively. There has been some discussion on the SG16 mailing list
> <https://lists.isocpp.org/sg16/2025/01/4503.php>; please try to review
> it before this meeting. We'll discuss any SG16 concerns and
> potentially poll forwarding the paper to EWG/LEWG.
>
> I initiated an SG16 mailing list review of P2758R4
> <https://lists.isocpp.org/sg16/2025/01/4512.php> last week, but it did
> not garner sufficient engagement to establish a consensus position.
> Please review the comments from those that did participate prior to
> this meeting. Thanks to Corentin for several corrections to the
> summary I provided in the review request. SG16 previously reviewed
> P2758R2 <https://wg21.link/p2758r2> during its 2024-04-10 meeting
> <https://github.com/sg16-unicode/sg16-meetings#april-10th-2024>. It
> looks to me like all of the previously raised SG16 concerns have been
> addressed. Previous discussion also considered the ability to suppress
> diagnostics with an in-source annotation. That hasn't been addressed,
> but isn't an SG16 concern, so we won't discuss it. Previous discussion
> also concerned handling of escape sequences. The paper hasn't
> explicitly addressed this, but escape sequences are also not relevant
> once a /string-literal/ object has been initialized. We have not, I
> think, discussed whether certain characters should be prohibited from
> user-provided diagnostic messages (e.g., control characters), or
> whether handling of such characters should be left as a QoI concern.
> See https://godbolt.org/z/e7fnc1qbb for an example of current QoI
> (MSVC does not yet implement P2741R3 (user-generated static_assert
> messages) <https://wg21.link/p2741r3>).
>
> Tom.
>
>