My understanding is that the motivation for fixed_string is exclusively the
need for a structural type (the name is deceptive).
See CTRE
https://github.com/hanickadot/compile-time-regular-expressions/blob/029f1f13646cf65ec09780013418cb8f1c5d3a59/include/ctll/fixed_string.hpp#L217


I'd be rather opposed to having more string types, especially if the goal
is to yet again fix language deficiencies.
Richard's excellent paper illustrates how we could make std::string
structural in the future
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2484r0.html#variable-length-representation
- I should hope that this future comes in time for this proposal to use it
:)
IE, richard proposal alleviates the need for fixed_string, rather than
allowing its implementation (which it would, sure, but it would remove the
motivation)

On Tue, Nov 28, 2023 at 7:36 PM Tom Honermann via SG16 <
sg16_at_[hidden]> wrote:

> 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>:
> - Support for a fixed_string type as referenced in the "External
> dependencies" section
> <https://wg21.link/p2980r0#external-dependencies>.
> - 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 <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.
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>