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.
Section: 23.2.2 [char.traits.require] Status: New Submitter: Jiang An Opened: 2022-05-04 Last modified: 2022-05-17
Priority: 4
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 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 beusing 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: