Created on 2022-05-04.00:00:00 last changed 1 week ago
[ 2022-05-17; Reflector poll ]
Set priority to 4 after reflector poll. One vote for NAD.
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 [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 11:58:16||admin||set||messages: + msg12466|