SG16 will hold a telecon on Wednesday, November 29th, at 19:30 UTC (timezone conversion).

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:
• Support for a fixed_string type as referenced in the "External dependencies" section.
• Support for std::format and display of symbol names.
• 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. The standard currently requires a type to be a structural type ([temp.param]p7) 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). 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 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 as well.

The idea of a fixed_string type has been around for quite some time. P0259 (fixed_string: a compile time string) 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) discussed a fixed_string type, but stopped short of proposing one. Richard Smith described and presented 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 for examples. Though not shown in the paper, the reference implementation describes a grammar for a std::format formatter. 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.