indirectly_readable is false for std::optional??

Hi,

I do not understand the following:



The resulting value when applying the operator* is the same reference type for const and non-const objects...


and therefore std::optional<> is not indirectly_readable....

why?



Last edited on
The resulting value when applying the operator* is the same reference type for const and non-const objects...

It means that the const-ness of the object being dereferenced should not affect the type of the pointed-to value.

For example, dereferencing an int* and an int* const both produce an int lvalue:
1
2
3
4
5
int* const cp = nullptr;
int* mp;
static_assert(std::same_as<decltype(*cp), decltype(*mp)>);
static_assert(std::same_as<decltype(*cp), int&>);
static_assert(std::same_as<decltype(*mp), int&>);

std::optional doesn't behave this way:
1
2
3
4
5
std::optional<int> const co;
std::optional<int> mo;
static_assert(! std::same_as<decltype(*co), decltype(*mo)>);
static_assert(std::same_as<decltype(*mo), int&>); 
static_assert(std::same_as<decltype(*co), int const &>); 

The purpose of indirectly_readable is to specify generic algorithms using iterators:
p1878 wrote:
The STL as specified assumes that the value category and const-ness of an iterator does not affect whether it can be dereferenced [...] a type such as std::optional no longer models readable because the return type of its unary operator* member is different depending on the const-ness of the std::optional. Presently, we have no examples of algorithms that are generic over pointer-and-iterator-like things and optional-like things, so the lack of a concept that can be used to constrain such algorithms is not troubling.

https://wg21.link/p1878
Last edited on
Topic archived. No new replies allowed.