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: 24.7.2.2.1 [span.overview] Status: New Submitter: Jiang An Opened: 2022-11-06 Last modified: 2022-11-12
Priority: 2
View other active issues in [span.overview].
View all other issues in [span.overview].
View all issues with New status.
Discussion:
This issue is discovered when implementing the span part of P2278R4 in MSVC STL.
P2278R4 added the const_iterator member type to std::span, which required its iterator type to model std::input_iterator (same for const_reverse_iterator and reverse_iterator). However, when element_type is volatile T and T is a class type, the iterator type generally fails to satisfy input_iterator, because:input_iterator<iterator> requires indirectly_readable<iterator>;
indirectly_readable<iterator> requires common_reference_with<iterator_reference_t<iterator>&&, iterator_rvalue_reference_t<iterator>&&>, that is common_reference_with<volatile T&, volatile T&&>;
common_reference_t<volatile T&, volatile T&&> is T (which is problematic), and thus common_reference_with<volatile T&, volatile T&&> requires both convertible_to<volatile T&, T> and convertible_to<volatile T&&, T>;
However, the class type T generally doesn't have constructors from volatile T or const volatile T glvalues, and thus neither convertible_to<volatile T&, T> and convertible_to<volatile T&&, T> is satisfied.
Ideally, span should not require any form of construction of element_type. Although usages of class types provided by the standard library via volatile glvalues are generally not supported, I think span<volatile T, E> is still useful for some user-defined class type T, and thus shouldn't be forbidden.
[Kona 2022-11-12; Set priority to 2]
Proposed resolution: