Implement LWG-3797 elements_view insufficiently constrained - #6310
Conversation
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
This PR implements LWG-3797 "elements_view insufficiently constrained" by adding a missing constraint to the _Has_tuple_element concept in C++23 mode, ensuring that get<N>(t) is convertible to const tuple_element_t<N, T>&. The pre-C++23 path already had this constraint, but it was inadvertently dropped when the C++23 _Tuple_like concept was introduced.
Changes:
- Added the
get<_Index>(__t) -> convertible_to<const tuple_element_t<_Index, _Tuple>&>constraint to the C++23 branch of_Has_tuple_element. - Added compile-only tests verifying that
elements_viewcorrectly rejects ranges whose element type has a move-only component (e.g., subranges with move-only input iterators), covering direct vectors, transformed views,as_const, andas_rvalue.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| stl/inc/ranges | Adds the missing requires constraint for get convertibility to _Has_tuple_element in C++23 mode |
| tests/std/tests/P0896R4_views_elements/test.cpp | Adds compile-time tests for LWG-3797 using move-only subranges and various view adaptors |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
I'm mirroring this to the MSVC-internal repo. Please notify me if any further changes are pushed, otherwise no action is required. |
77a04d8
into
microsoft:main
😻 💚 💝 |
Fixes #6204.
However, it seems that
elements_viewbecomes overconstrained with this fix, although it was already overconstrained in C++20. Currently (after LWG-3797) the following code is rejected, while it seems to me that it can be made to work.Seems like that the constraints of
elements_vieware somehow imprecise. Especially,_Has_tuple_elementdoesn't seem to handle rvalues well. IMO, ideally, they should only match validness of iterator'soperator*while additionally requiring tuple-like-ness.