Skip to content

Conversation

@Ukilele
Copy link
Contributor

@Ukilele Ukilele commented Apr 21, 2022

Fixes #2536

@Ukilele Ukilele requested a review from a team as a code owner April 21, 2022 17:16
@StephanTLavavej StephanTLavavej added ranges C++20/23 ranges cxx23 C++23 feature labels Apr 21, 2022
Copy link
Contributor

@strega-nil-ms strega-nil-ms left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have not yet reviewed the tests, though I have reviewed all the product code.

This looks really fantastic! It looks like it follows the standard pretty directly, and I don't have a lot of concerns with it.

The only major things I see are some weirdnesses with remove_cvref_t, some reorderings, and the ABI concern with _Pipe::_Base and range_adaptor_closure. I recommend making range_adaptor_closure<_Ty> derive from _Pipe::_Base<_Ty> so as to reuse that code, and revert existing uses of _Pipe::_Base back to _Pipe::_Base.

Thank you so much!

Copy link
Contributor

@strega-nil-ms strega-nil-ms left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tests look great :)

Most notably, `range_adaptor_closure<T>` now derives from `_Pipe::_Base<T>`, and the standard range adaptor closure objects derive directly from `_Pipe::_Base` as they did previously. I also eliminated a ton of repetition by implementing `operator|` for `_Pipe::_Base` as a non-member. (Since the non-member operator is squirreled away in `std::ranges::_Pipe` it is still effectively only found by ADL for things derived from `_Pipe::_Base` despite no longer being a hidden friend.)
@CaseyCarter
Copy link
Contributor

CaseyCarter commented Aug 19, 2022

This is incredible @Ukilele - thanks! I've pushed changes to (1) merge with main and resolve conflicts, (2) address the ABI concerns, and (3) simplify the "is this a range adaptor" concept a bit.

@StephanTLavavej StephanTLavavej self-assigned this Aug 20, 2022
@StephanTLavavej
Copy link
Member

I'm speculatively mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

&& constructible_from<remove_cvref_t<_Left>, _Left> //
&& constructible_from<remove_cvref_t<_Right>, _Right> //
_NODISCARD constexpr auto operator|(_Left&& __l, _Right&& __r) noexcept(
noexcept(_Pipeline{static_cast<_Left&&>(__l), static_cast<_Right&&>(__r)})) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ugh, this formatting is hideous, but not worth resetting the port. I'll clean these in a followup.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Yeah, I noticed how icky it was - perhaps because [[nodiscard]] is being concealed with the macro.

@StephanTLavavej StephanTLavavej dismissed strega-nil-ms’s stale review August 22, 2022 20:53

Casey addressed Nicole's comments

@StephanTLavavej StephanTLavavej merged commit 2ae879b into microsoft:main Aug 22, 2022
@StephanTLavavej
Copy link
Member

Thanks for making this ranges plumbing available to users! 😹 🎉 🚀

@Ukilele Ukilele deleted the pipe_for_user_defined_range_adaptors branch August 23, 2022 06:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cxx23 C++23 feature ranges C++20/23 ranges

Projects

None yet

Development

Successfully merging this pull request may close these issues.

P2387R3 Pipe Support For User-Defined Range Adaptors

9 participants