US264 23.03.4.2 Problems with "readable" concept P1878

[wg21bot]

The readable concept is both under- and over-constrained. It is under-constrained in that it permits its associated types (iter_value_t, iter_reference_t, etc) to differ depending on whether the type is const-qualified or not. It might make sense for iter_reference_t to be sensitive to const-ness if, for example, it is our intention for a type like optional to satisfy readable. Generally we use readable to constrain types that are logical indirections; e.g., pointers (smart and dumb) and iterators. For those, top-level cv-qualification should not matter.

readable is over-constrained because it only requires operator* to be valid on a (non-const) lvalue.

See discussion at ericniebler/stl2#514

Proposed change:
Change the definition of the readable concept to correct these problems.

[wg21bot]

Related to US263 #259.

[mclow]

This contains some design issues that LEWG should weigh in on.
P1878 proposes a resolution for this.

[tituswinters]

LEWG in Belfast: Forward P1878 (with revisions to the concept names, as readable/writable are more accurately indirectly_readable/indirectly_writable) to LWG for C++20.

(Prioritization on this vs. other paper-sized NB comments will be shared with LWG chair when LEWG finishes NB comment processing.)

[JeffGarland]

LWG small group on Wednesday morning -- paper needs updates for indirectly_writable before full LWG review.

[JeffGarland]

Reviewed and adopted by large group on Wednesday. indirectly_writable was covered by global replace editors note.

straw polls to adopt for C++20
F N A
13 0 1

[jensmaurer]

Accepted with modification. See paper P1878R1.