SG16 will hold a meeting on Wednesday, February 5th, at 19:30 UTC (timezone conversion).

If you need a .ics file to import into your calendar, you can download it here.

The agenda follows.

• P3560R0: Error Handling in Reflection.
• P2758R4: Emitting messages at compile time.

P3560R0 proposes changing how errors encountered during reflection operations are handled. P2996R9 (Reflection for C++26) 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) 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; 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 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 during its 2024-04-10 meeting. 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)).

Tom.