SG16 will hold a meeting *today*, Wednesday, March 26th, at 19:30 UTC
(timezone conversion
<https://www.timeanddate.com/worldclock/converter.html?iso=20250326T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cet>).

Once again, my apologies for sending the agenda so late.

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/5FDDA8FA-1102-44AC-8E03-DC78F1B95BB6.ics?export>.

The agenda follows.

  * P3491R2: define_static_{string,object,array}
    <https://wg21.link/p3491r2>.
  * P3391R0: constexpr std::format <https://wg21.link/p3391r0>.

The features proposed in *P3491R2* were previously discussed in SG16 in
the context of P2996R5 (Reflection for C++26)
<https://wg21.link/p2996r5> during the 2024-08-14 meeting
<https://github.com/sg16-unicode/sg16-meetings/blob/master/README.md#august-14th-2024>.
As P2996 progressed, these features were split to the new paper. The
guidance we provided in that meeting was to remove
define_static_string() in favor of adding define_static_array() as a
means to avoid questions about null terminators for strings. The new
paper proposes both define_static_string() and define_static_array() (as
well as define_static_object()), but addresses the null termination
question by statically determining if the range passed to
define_static_string() corresponds to a string literal; if it does, then
the null terminator presumed to be present in the range is ignored. A
possible implementation of define_static_string() is described in
section 3.3, "Possible Implementation". The ability to check if a
pointer points to a (portion of a) string literal during constant
evaluation is also exposed via a suite of is_string_literal() overloads.
We'll discuss this new design and, if all goes well, poll forwarding the
paper. Note that LEWG has already forwarded this paper for C++26 and any
concerns we identify that would require design changes will presumably
have to be addressed as LWG issues.

*P3391R0* seeks to make std::format() available during constant
evaluation with appropriate limitations. The proposal omits support for
std::chrono types which saves us the effort of having to decide how to
handle the locale dependent conversion specifiers from [time.format]
<https://eel.is/c++draft/time.format>. The proposal does not add
constexpr to the std::format() overloads that have a std::locale
parameter, but it is currently silent regarding handling of the L option
for the standard format specifiers in [format.string.std]
<https://eel.is/c++draft/format.string.std>. We'll discuss and provide
guidance regarding handling of that option. Possibilities include
excluding calls that specify this option during constant evaluation or
specifying the behavior as-if for the "C" locale. Note that none of
std::locale::classic(), std::locale::global(), the std::locale
constructors, or the std::locale facets are currently declared constexpr.

Tom.