Date: Tue, 15 Oct 2024 13:14:42 +0200
On 14/10/2024 22.04, Mateusz Pusz via SG16 wrote:
> Also, how should I construct a `string_view` from it? Should I use the default `char_traits<CharT>`?
Yes.
> pon., 14 paź 2024 o 22:00 Mateusz Pusz <mateusz.pusz_at_[hidden] <mailto:mateusz.pusz_at_[hidden]>> napisał(a):
>
> Hi,
>
> Can someone provide me a proper rationale for removing `char_traits`?
char_traits promises configurability for operations where no user-level
configuration makes sense.
The CharT template parameter needs to be a char-like type
([strings.general]), which means it's trivial, and the implementation
thus doesn't need char_traits to enable "memcpy"-style optimizations.
For the comparisons, having char_traits that implement case-insensitive
comparisons is oversimplifying, because case-insensitivity is locale-dependent.
Also, encoding such comparison semantics into a data type seems bad design.
Having a survey of user-provided specializations of char_traits out in the
wild would be good.
Jens
> Also, how should I construct a `string_view` from it? Should I use the default `char_traits<CharT>`?
Yes.
> pon., 14 paź 2024 o 22:00 Mateusz Pusz <mateusz.pusz_at_[hidden] <mailto:mateusz.pusz_at_[hidden]>> napisał(a):
>
> Hi,
>
> Can someone provide me a proper rationale for removing `char_traits`?
char_traits promises configurability for operations where no user-level
configuration makes sense.
The CharT template parameter needs to be a char-like type
([strings.general]), which means it's trivial, and the implementation
thus doesn't need char_traits to enable "memcpy"-style optimizations.
For the comparisons, having char_traits that implement case-insensitive
comparisons is oversimplifying, because case-insensitivity is locale-dependent.
Also, encoding such comparison semantics into a data type seems bad design.
Having a survey of user-provided specializations of char_traits out in the
wild would be good.
Jens
Received on 2024-10-15 11:14:47