Open
Description
As we all know, it is unreasonable to create basic_istream
during compile-time. However, the member functions of basic_istream_view
are all declared as constexpr
. 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 of basic_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 (although end()
can be constexpr
by its implementation)?
Did I miss something?
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
frederick-vs-ja commentedon Jan 5, 2024
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 whereconstexpr
triggers additional instantiation which can be ill-formed for some incomplete types?constexpr
works even without support forconstexpr basic_istream
!The
constexpr
on the constructor andend
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.The situations where
constexpr
onbegin
and the constructor of the iterator work are currently present, despite extremely contrived.The status quo is inconsistent as there're non-
constexpr
functions. It's possibly reasonable to addconstexpr
to bothoperator++
s andoperator*
, but not to theoperator==
.hewillk commentedon Jan 5, 2024
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?
std::generator::end
is completelyconstexpr
-able but it doesn't, because coroutine, like istream, is completely a run-time thing. Addingconstexpr
to it is of debatable value in my opinion.jensmaurer commentedon Jan 5, 2024
This is not an editorial concern, it seems.