Open yaito3014 opened 2 weeks ago
Hello, @yaito3014 , thanks for reporting the issue. Could you please submit an LWG issue? For bug fixes, we don’t have to go through LEWG.
https://cplusplus.github.io/LWG/lwg-active.html#submit_issue The email address for submitting issue is on the top of that page
the issue will be then discussed in the reflector and if enough people voted P0, potentially it be tentatively ready for next committee meeting
Thank you for response. I'm currently writing an email. 🚀
P.S. I have submitted the issue to the list.
I found a possible issue in
concat_view
's implementation.There is a case that
concat(a, b)
compiles butconcat(b, a)
does not.The reason behind this is as follows:
Firstly, if all
Views...
satisfy thestd::ranges::range
concept, thenconcat_view
should also satisfy it. However, if any of theViews...
have a non-copyable iterator and the last view iscommon_range
, the proposedconcat_view
fails to model a range.For
concat_view
to model a range, its sentinel must satisfystd::semiregular
, butconcat_view::end()
returns aconcat_view::iterator
, which is non-copyable if the underlying iterator is non-copyable. This issue arises from the proposed implementation, where the iterator usesstd::variant
. Although this specification is exposition-only, even if an alternative type-erasure mechanism is used, copying is still required if the user attempts to copy an iterator.To resolve the issue,
concat_view::end()
can fallback to returningstd::default_sentinel
in such cases.Unfortunately, as a side effect, this fix would prevent
concat_view
from being acommon_range
in certain situations. According to P2542R8:However, this is no longer true after applying my fix. On the other hand, the current draft (N4988) does not mention when
concat_view
can modelcommon_range
. I assume this omission was for simplicity, but I think the new behavior should be documented as a side note.That said, these two issues cannot be resolved simultaneously due to implementability. Therefore, I suggest applying the fix regardless and accepting that
concat_view
will not always inheritcommon_range
.I think this issue should be re-evaluated by LEWG or LWG before C++26 is shipped. Could I ask you to review the problem as the author?