This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

### 3694. Should `traits_type::length` be customizable?

Section: 23.2.2 [char.traits.require] Status: New Submitter: Jiang An Opened: 2022-05-04 Last modified: 2022-05-17

Priority: 4

View other active issues in [char.traits.require].

View all other issues in [char.traits.require].

View all issues with New status.

Discussion:

MSVC STL's implementation of the `std::quoted` overload for `const charT*` calculates the length of the NTCTS and stores the result within the return value. Because the returned value may be output by `std::basic_ostream` specializations with different `traits_type`s, this strategy can be conforming only if all possible `traits_type::length` functions for the same `char_type` have equivalent return values.

It seems not clear whether `traits_type::length` should be customizable. In a related PR, Stephan T. Lavavej said :

> I argue that you've found a defect in the `char_traits` specification — it should say that whatever `eq()` does, it should consider `charT()` to be distinct from all other values, which aligns with the common understanding of how null-terminated strings behave.

> The original implementation and the `char_traits::length` change both handle arbitrary character types — the only difference would be for custom `char_traits` that consider null terminators to be equal to other values, which I have never seen used in practice (e.g. case-insensitive traits don't do this).

If it is decided that `traits_type::length` is customizable, then the implementation in MSVC STL should be fixed. Otherwise, we should explicitly require in 23.2.2 [char.traits.require] that whenever `c` is not "equal" to `char_type()`, `traits_type::eq(c, char_type())` is `false`.

However, equivalence of two `charT` values seems not easy to specify, as there may be no `operator==` for `charT`, or the `operator==` behaves pathologically. IMO possible way may be

- using the equivalence relation of value representations, or

- using `==` and only imposing the requirement when `char_type` is an encoded character type (or more generally, a scalar type, while treating an enum type as its underlying type).

[2022-05-17; Reflector poll]

Set priority to 4 after reflector poll. One vote for NAD.

Proposed resolution: