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.