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: 27.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_types, 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 27.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: