SG16 will hold a telecon on Wednesday, November 29th, at 19:30 UTC
(timezone conversion
<https://www.timeanddate.com/worldclock/converter.html?iso=20231129T193000&p1=1440&p2=tz_pst&p3=tz_mst&p4=tz_cst&p5=tz_est&p6=tz_cet>).

*Since I am, once again, so late in sending this out, let this notice be
your friendly reminder that this meeting is taking place tomorrow (in
about 25 hours).*

*Please note that daylight savings time has ended in both North America
and in Europe since we last met, so this meeting will start one hour
earlier than the last one. Please check your calendars!*

The agenda follows.

  * P2980R0: A motivation, scope, and plan for a physical quantities and
    units library <https://wg21.link/p2980r0>:
      o Support for a fixed_string type as referenced in the "External
        dependencies" section
        <https://wg21.link/p2980r0#external-dependencies>.
      o Support for std::format and display of symbol names.
      o Support for wchar_t, char8_t, char16_t, and char32_t.

The first item we'll discuss is requirements for a fixed_string type; a
type that would be suitable for use as a non-type template parameter
(NTTP) and that is capable of holding a string (a sequence of code
units, presumably with a null terminator) of up to a compile-time fixed
length. The paper does not currently discuss its own requirements for
such a type, but they appear to be minimal; see the named_unit examples
in the "Extensibility" section
<https://wg21.link/p2980r0#extensibility>. The standard currently
requires a type to be a /structural type/ ([temp.param]p7
<http://eel.is/c++draft/temp.param#7>) to be used as a NTTP and that
imposes imitations on how fancy such a type can be (see the /literal
type/ definition in [basic.types.general]p10
<http://eel.is/c++draft/basic.types.general#10>). The proposal could go
forward with a bespoke exposition-only type that satisfies just the
needs of that proposal. The questions for SG16 to consider are:

 1. Should the proposal be blocked on the availability of a standard
    fixed_string type or should the authors feel free to proceed with a
    less general type (in which case it should not squat on a good name)?
 2. What properties should a general fixed_string type satisfy?
     1. Should it be read-only or read-write?
     2. Should it be resizeable within the limits of the fixed capacity?
     3. Should it provide all the relevant member functions from
        std::string and std::string_view?
     4. Should it support all of wchar_t, char8_t, char16_t, and char32_t?

The reference implementation <https://github.com/mpusz/mp-units/>
currently uses a read-only implementation; see the first link in the
list below. Examples uses can be seen in
https://github.com/mpusz/mp-units/blob/master/src/systems/si/include/mp-units/systems/si/units.h.
The reference implementation is available on godbolt.org
<https://godbolt.org/z/14xG31rb3> as well.

The idea of a fixed_string type has been around for quite some time.
P0259 (fixed_string: a compile time string) <https://wg21.link/p0259>
proposed a basic_fixed_string class template, but it was proposed as a
constexpr version of std::string and not for use as a NTTP. That
proposal has been made mostly obsolete by constexpr support for
std::string. P0732 (Class Types in Non-Type Template Parameters)
<https://wg21.link/p0732> discussed a fixed_string type, but stopped
short of proposing one. Richard Smith described
<https://lists.isocpp.org/ext/2019/06/10317.php> and presented
<https://wiki.edg.com/pub/Wg21belfast/EvolutionWorkingGroup/US114.pdf>
an operator template mechanism to allow a type that is not a /structural
type/ to provide its own method of encoding as a template parameter, but
a formal proposal has not been submitted. If adopted, such a mechanism
could be useful for the implementation of a fixed_string type.

There are numerous implementations of a fixed_string type available:

  * https://github.com/mpusz/mp-units/blob/master/src/core/include/mp-units/bits/external/fixed_string.h
    A read-only implementation.
  * https://github.com/mpusz/inplace_string/blob/master/src/include/mp/inplace_string.h
    A read/write/resizable implementation that behaves like std::string.
  * https://www.boost.org/doc/libs/1_83_0/libs/static_string/doc/html/index.html
    A read/write/resizable implementation that behaves like std::string.
  * https://github.com/unterumarmung/fixed_string
    A read/write/resizable implementation that behaves like std::string.
  * https://github.com/tomazos/fixed_string/blob/master/fixed_string.h
    A read/write/resizable implementation of P0259 that behaves like
    std::string.

The proposal also discusses integration with std::format and iostreams,
but is light on details at present. See the "Look and feel" section
<https://wg21.link/p2980r0#look-and-feel> for examples. Though not shown
in the paper, the reference implementation describes a grammar for a
std::format formatter
<https://mpusz.github.io/mp-units/2.1/users_guide/framework_basics/text_output/#stdformat>.
That grammar includes a /units-text-encoding/ production that allows the
programmer to select between Unicode and ASCII symbols. Whether such
manual selection is appropriate and how it interacts with encoding is
clearly an SG16 concern. See the unit test examples in
https://github.com/mpusz/mp-units/blob/master/test/unit_test/static/unit_symbol_test.cpp.

Finally, if time permits, we'll discuss wchar_t, char8_t, char16_t, and
char32_t support. Since neither iostreams nor std::format support the
charN_t types at present, there likely isn't much to discuss there. I
might be mistaken, but the reference implementation does not appear to
support wchar_t at present.

Tom.