Feedback on 'P2387R3: Pipe support for user-defined range adaptors'

[mtezych]

Hello Barry, I've recently implemented in C++20 a custom range adaptor cxx::chunk_evenly():

• [GitHub] - chunk_evenly.hxx

While doing so, I've realized that, in order to have the ability to use the pipe operator, I need to implement the std::ranges::range_adaptor_closure class template from P2387R3:

• [GitHub] - range_adaptor_closure.hxx

After getting myself familiar with P2387R3, I want to say that, I am strongly in favor of it and glad that it was accepted into the C++23 draft. Finally all C++ developers will have the ability to implement custom range adaptors, which will be composable with standard range adaptors!

However, even though the cxx::ranges::range_adaptor_closure_interface class template does not support composing, via the pipe operator, custom range adaptor closures with standard range adaptor closures, and therefore, when creating a pipeline, the cxx::chunk_evenly() range adaptor is not composable with standard range adaptors:

• [Compiler Explorer] - create a pipeline

  const auto pipeline = cxx::chunk_evenly(3) | std::views::take(2);
  //                                         ^
  //                                         |___ does not compile!

  it still has a couple of advantages, compared to the std::ranges::range_adaptor_closure, which I think are worth adopting:

• more suitable name The std::ranges::range_adaptor_closure is not a range adaptor closure itself. It is a class template, which range adaptor closures (or rather types, which aim to model the range_adaptor_closure concept) should inherit from CRTP-style.

  Since that class template provides essential part of the interface, that all range adaptor closures are characterized by, that is invocability and composability via the pipe operator, it should be renamed to std::ranges::range_adaptor_closure_interface.

  Please notice that, the proposed new name will be consistent with the std::ranges::view_interface class template, which has a similar role in the context of the std::ranges::view concept.

  Moreover the name std::ranges::range_adaptor_closure should be reserved for the range_adaptor_closure concept, which represents the set of types of all range adaptor closure objects.

• constrained pipe operators The definition of the std::ranges::range_adaptor_closure concept is actually already specified in 26.7.2 [range.adaptor.object].

  Unfortunately defining the std::ranges::range_adaptor_closure concept in practice is incredibly difficult, since it requires defining an archetype for the std::ranges::viewable_range concept, which I just was not able to do.

  Side Note:

  Since, a range adaptor object is a customization point object that accepts a viewable_range as its first argument and returns a view, a range adaptor closure object should be a unary function object that accepts a viewable_range as its only argument.

  Fortunately I was able to define two (exposition-only) concepts:

  1. cxx::ranges::maybe_range_adaptor_closure
  2. cxx::ranges::range_adaptor_for<viewable_range>

  and at least partially constrain the pipe operators using them.

  Ideally the std::ranges::range_adaptor_closure concept would be added to the standard library, since it would be useful for defining customizable pipelines:

  auto create_pipeline (std::ranges::range_adaptor_closure auto&& op)
  {
    return std::views::take(2) | op | std::views::reverse;
  }

  However, this can be done in a future C++ standard and requiring the std::ranges::range_adaptor_closure_interface class template to provide at least partially constrained pipe operators is better than nothing.

I hope this feedback is valuable and it is not tool late to at least rename the std::ranges::range_adaptor_closure to std::ranges::range_adaptor_closure_interface before C++23 will approved and released.

Thank you, Mateusz Zych

[frederick-vs-ja]

viewable_range seems pointless at least after P2387. It is only used in the standard library via views::all_t, but given views::all is well-constrained (due to the fix in LWG3724), perhaps we should just rely on the native constraints on views::all.

The remain use of viewable_range in [range.adaptor.object] looks like a defect to me.

[frederick-vs-ja]

the cxx::chunk_evenly() range adaptor is not composable with standard range adaptors:

It seems that the implementation of range_adaptor_closure must be coupled with the implementation details of standard range adaptors to support composing. This doesn't seem an issue to me given range_adaptor_closure is std::ranges::range_adaptor_closure.