On 11/28/23 2:14 PM, Corentin Jabot wrote:
> 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
>

Motivation also exists for scenarios where dynamic memory allocation is
not allowed, but that is an orthogonal concern.

Thanks for the CTRE reference; I missed that one.

>
> I'd be rather opposed to having more string types, especially if the
> goal is to yet again fix language deficiencies.
That was my motivation for trying to see if std::basic_string could be
employed in defining such a type. That doesn't really avoid a new type
of course; it just introduces it as a new family of class template
specializations that don't necessarily interact well with other
specializations.
> 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)

Ohh, thank you for that reference! I wasn't aware of that paper and
Richard didn't mention it when I recently asked him if there had ever
been a formal proposal for operator template. Richard did note that
P2308 (Template parameter initialization) <https://wg21.link/p2308> is
needed to unblock such a proposal though (P2308 was recently approved by
CWG
<https://github.com/cplusplus/papers/issues/1469#issuecomment-1815227332>
and should be coming soon to a plenary near you).

I agree that the best fixed_string would be std::string if we can get there.

Tom.

>
> 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>:
>> 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.
>>
>>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>