-
Notifications
You must be signed in to change notification settings - Fork 13.4k
[libc++] Implement views::join_with
#65536
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
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
@JMazurkiewicz At the top you mention that this PR completed several papers. Do you need to add additional GitHub issues to the list that this PR closes/fixes/? |
Instead of `// UNSUPPORTED: c++03, c++11, c++14, c++17, c++20`
Ping @huixie90 |
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.
LGTM with some nits. Thanks very much for the patch!
@@ -47,6 +47,9 @@ Implemented Papers | |||
- P1222R4: A Standard ``flat_set`` (`Github <https://github.com/llvm/llvm-project/issues/105193>`__) | |||
- P2897R7: ``aligned_accessor``: An mdspan accessor expressing pointer over-alignment (`Github <https://github.com/llvm/llvm-project/issues/118372>`__) | |||
- P3247R2: Deprecate the notion of trivial types (`Github <https://github.com/llvm/llvm-project/issues/118387>`__) | |||
- P2441R2: ``views::join_with`` (`Github <https://github.com/llvm/llvm-project/issues/105185>`__) | |||
- P2711R1: Making multi-param constructors of ``views`` ``explicit`` (`Github <https://github.com/llvm/llvm-project/issues/105252>`__) |
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.
question: is this paper completely done? I saw P2441R2 has multiple changes in different views
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.
I think the rest of P2711 is already done in libc++ 17.
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.
I confirm. I think it was my first contribution.
|
||
[[__nodiscard__]] _LIBCPP_HIDE_FROM_ABI constexpr _View base() && { return std::move(__base_); } | ||
|
||
[[__nodiscard__]] _LIBCPP_HIDE_FROM_ABI constexpr auto begin() { |
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.
is there a reason why [[__nodiscard__]]
is used rather than [[nodiscard]]
?
also I notice that we don't add [[nodiscard]]
in ranges library yet. not that I am against nodiscard, but I am not sure what we generally do in this case. For example, begin
can be mutating and there might be a legitimate use case where begin
is called explicitly to cache the results and discard 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.
@ldionne I wonder what is the policy in Libc++ for adding no_discard
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.
This should use the non-ugly spelling. Re. policy, we have https://libcxx.llvm.org/CodingGuidelines.html#apply-nodiscard-where-relevant. In this case I think it's fine. This would most likely fall under "only observe a value" or "is most likely a misuse of the function". While it's technically possible that someone might call begin()
to cache something, this would definitely require a comment in code, and having to add a void cast seems fine to me in that case.
struct __join_with_view_iterator_category {}; | ||
|
||
template <class _Base, class _PatternBase, class _InnerBase> | ||
requires is_reference_v<range_reference_t<_Base>> && forward_range<_Base> && forward_range<_InnerBase> |
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.
is_reference_v<range_reference_t<_Base>>
is still correct but the spec is using is_reference_v<InnerBase>
, which is simpler
template <bool _OtherConst> | ||
requires sentinel_for<sentinel_t<_Base>, iterator_t<__maybe_const<_OtherConst, _View>>> | ||
[[__nodiscard__]] _LIBCPP_HIDE_FROM_ABI constexpr bool __equal_to(const __iterator<_OtherConst>& __x) const { | ||
return __x.__get_outer() == __end_; |
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 is the reason to have this member function? is it just for the private access? if so, i would recommend to just have a static member function to access the private member of iterator
. it is quite verbose here with the complex requires
expression
Sorry for the churn about the |
views::join_with
" (https://wg21.link/P2441R2), closes P2441R2:views::join_with
#105185compatible-joinable-ranges
is underconstrained #105346views
explicit
#105252iterators
for proper flattening #105250