Allow both ::value_type and ::element_type in indirectly_readable_traits

[Casey Carter (CaseyCarter)]

Per [readable.traits], indirectly_readable_traits::value_type is the same type as remove_cv_t if it denotes an object type, or remove_cv_t if it denotes an object type. If both T::value_type and T::element_type denote types, indirectly_readable_traits::value_type is ill-formed. This was perhaps not the best design, given that there are iterators in the wild (Boost's unordered containers) that define both nested types. indirectly_readable_traits should tolerate iterators that define both nested types consistently.

Fixes VSO-1121031.

[Stephan T. Lavavej (StephanTLavavej)]

Looks perfect to me - thanks for the "LWG issue pending" comment.

[Michael Schellenberger Costa (miscco)]

I am gonna play dumb here (and you have to pretend that it is only a play Ha)

If the type does not have element_type but value_type is the second constraint-expression ill formed?

In my head I thought that we need to ensure that all constraints are well formed. Could we test that this does not blow up with a type that only features a value_type?

[Curtis J Bezault (cbezault)]

I believe that constraints are supposed to be short-circuited and evaluated from left to right.

From [temp.constr.op] A conjunction is a constraint taking two operands.
To determine if a conjunction is satisfied, the satisfaction of the first operand is checked.
If that is not satisfied, the conjunction is not satisfied.
Otherwise, the conjunction is satisfied if and only if the second operand is satisfied.

[Casey Carter (CaseyCarter)]

SFINAE is in effect in constraints: substitution failure in an atomic constraint expression causes the constraint to be dissatisfied, rather than ill-formed. It's also the case, as Curtis J Bezault (@cbezault) mentions, that substitution and evaluation occur in lockstep, with satisfaction short-circuiting disjunctions and dissatisfaction short-circuiting conjunctions.

This constraint could equivalently be:

template <class T>
    requires same_as<remove_cv_t<typename T::value_type>,
        remove_cv_t<typename T::element_type>>
struct indirectly_readable_traits {};

but I have a style guideline that requires all typenames formed to be first mentioned in a type-requirement which hopefully makes it easier for compilers to provide good diagnostics.

[Casey Carter (CaseyCarter)]

Oops: I should have mentioned that MSVC has a substitution bug; it wants to substitute T into typename T::meow too early (https://godbolt.org/z/9w9uPZ):

template <class> inline constexpr auto meow = false;

template <class T> concept C = 
    true || meow<typename T::X>;

static_assert(C<int>);

which isn't a problem for this case.