Open hewillk opened 9 months ago
Would it be more appropriate to remove all
constexpr
qualifiers from this section (althoughend()
can beconstexpr
by its implementation)?
I think some or all constexpr
specifiers in [range.istream.view] may be unintended. But they don't seem defective and work in some edge cases. Can we find a case where constexpr
triggers additional instantiation which can be ill-formed for some incomplete types?
constexpr
works even without support for constexpr basic_istream
!
The `constexpr` on the constructor and `end` definitely make some sense (although not so much). E.g. the following is currently [well-formed](https://godbolt.org/z/1TWePjK3K), and I don't think it make much sense to make it ill-formed.
```C++
#include
The status quo is inconsistent as there're non-constexpr
functions. It's possibly reasonable to add constexpr
to both operator++
s and operator*
, but not to the operator==
.
But they don't seem defective and work in some edge cases.
Although they can work in some edge cases, these cases are useless and unreasonable in my opinion. Could you come up with some really meaningful cases?
The constexpr on the constructor and end definitely make some sense (although not so much). E.g. the following is currently well-formed, and I don't think it make much sense to make it ill-formed.
std::generator::end
is completely constexpr
-able but it doesn't, because coroutine, like istream, is completely a run-time thing. Adding constexpr
to it is of debatable value in my opinion.
This is not an editorial concern, it seems.
As we all know, it is unreasonable to create
basic_istream
during compile-time. However, the member functions ofbasic_istream_view
are all declared asconstexpr
. I don’t quite understand why?If the intention here is to support
constexpr basic_istream
(which is not unreasonable), then why are almost all the members ofbasic_istream_view::iterator
non-constexpr
except for the constructor? I'm confused by such inconsistency.Would it be more appropriate to remove all
constexpr
qualifiers from this section (althoughend()
can beconstexpr
by its implementation)?Did I miss something?