I spent a little time trying to see how far I could get in implementing
a fixed_string type using std::basic_string with a custom fixed capacity
allocator that uses a data member for storage. For anyone interested see
https://godbolt.org/z/zE37E43fz. There are some non-trivial problems
that would have to be addressed to make that work.

I think this exposed a bug in the libc++ implementation of
std::basic_string. Its max_size() computation appears to be off and can
be exceeded.

Tom.

On 11/28/23 1:29 PM, Tom Honermann via SG16 wrote:
>
> 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.
>
>