-
Notifications
You must be signed in to change notification settings - Fork 11.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[libc++] Implement views::join_with
#65536
base: main
Are you sure you want to change the base?
Conversation
3259db4
to
0481670
Compare
0481670
to
f113229
Compare
@JMazurkiewicz Please ping us when this is ready to review and make it a non-draft. |
f113229
to
1835f68
Compare
✅ With the latest revision this PR passed the C/C++ code formatter. |
I guess with constexpr variant this cool feature can be finalized now :) |
a84985a
to
fcdf64a
Compare
54a741c
to
a9a1031
Compare
a9a1031
to
9406093
Compare
* Implement "P2441R2 `views::join_with`" (https://wg21.link/P2441R2) * Complete implementation of "P2711R1 Making multi-param constructors of views explicit" (https://wg21.link/P2711R1) * Complete implementation of "P2770R0 Stashing stashing iterators for proper flattening" (https://wg21.link/P2770R0)
9406093
to
698bdd6
Compare
@JMazurkiewicz We have guidelines for applying |
Gentle ping on this PR -- do you think you'll have time to pick it up or should we find someone else to get it through the finish line? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the patch. it looks really good. I started looking at the join_with_view.h and has not finished the header yet.
|
||
namespace ranges { | ||
template <class _Range, class _Pattern> | ||
concept __compatible_joinable_ranges = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The spec is specified as concatable
after LWG4074. Perhaps directly use the new resolution
|
||
_LIBCPP_NODISCARD _LIBCPP_HIDE_FROM_ABI constexpr auto begin() const | ||
requires forward_range<const _View> && forward_range<const _Pattern> && | ||
is_reference_v<range_reference_t<const _View>> && input_range<range_reference_t<const _View>> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
might as well address LWG4074
|
||
_LIBCPP_NODISCARD _LIBCPP_HIDE_FROM_ABI constexpr auto end() const | ||
requires forward_range<const _View> && forward_range<const _Pattern> && | ||
is_reference_v<range_reference_t<const _View>> && input_range<range_reference_t<const _View>> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please address LWG4074 since you are adding new code
join_with_view(_Range&&, range_value_t<range_reference_t<_Range>>) | ||
-> join_with_view<views::all_t<_Range>, single_view<range_value_t<range_reference_t<_Range>>>>; | ||
|
||
template <class _Base, class _PatternBase> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: you can add a third template argument class _InnerBase = range_reference_t<_Base>
if you want, to simplify the code below a bit, since range_reference_t<_Base>
is used a lot of places in the code below and it is already mentioned as InnerBase
in the standard
|
||
static constexpr bool _UseOuterItCache = !forward_range<_View>; | ||
using _OuterItCache = _If<_UseOuterItCache, __non_propagating_cache<iterator_t<_View>>, __empty_cache>; | ||
_LIBCPP_NO_UNIQUE_ADDRESS _OuterItCache __outer_it_; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we have a test for this no_unique_address
? that is, if we don't need the cache, the test should check that we don't waste the memory
|
||
static constexpr bool _UseInnerCache = !is_reference_v<_InnerRng>; | ||
using _InnerCache = _If<_UseInnerCache, __non_propagating_cache<remove_cvref_t<_InnerRng>>, __empty_cache>; | ||
_LIBCPP_NO_UNIQUE_ADDRESS _InnerCache __inner_; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as above. do we have a test for the no_unique_address
?
|
||
static constexpr bool _OuterIterPresent = forward_range<_Base>; | ||
using _OuterIterType = _If<_OuterIterPresent, _OuterIter, std::__empty>; | ||
_LIBCPP_NO_UNIQUE_ADDRESS _OuterIterType __outer_it_ = _OuterIterType(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we have a test that if we don't store the outer iterator here, we don't waste the space?
using _OuterIterType = _If<_OuterIterPresent, _OuterIter, std::__empty>; | ||
_LIBCPP_NO_UNIQUE_ADDRESS _OuterIterType __outer_it_ = _OuterIterType(); | ||
|
||
variant<_PatternIter, _InnerIter> __inner_it_; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what happens if the variant
is in the valueless_by_exception
state? is it worth adding assertions in the member functions we are not in that state?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per current standard wording, some operations are required to throw bad_variant_access
. It's unclear whether this is intended, and LWG4059 intends to make such operations UB when valueless_by_exception
.
} | ||
|
||
_LIBCPP_NODISCARD _LIBCPP_HIDE_FROM_ABI constexpr decltype(auto) operator*() const { | ||
using __reference = common_reference_t<iter_reference_t<_InnerIter>, iter_reference_t<_PatternIter>>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we have tests that the __reference of inner and pattern results in a completely different type?
I'll take care of this PR again, starting next week. |
views::join_with
" (https://wg21.link/P2441R2)Fixes #105185