search

ericniebler / range-v3

Range library for C++14/17/20, basis for C++20's std::ranges
Other
4.13k stars 439 forks source link

difficult to compose own adaptors with range-v3's #1113

Open h-2 opened 5 years ago

h-2 commented 5 years ago

The current draft standard states:

For a range adaptor closure object C [...] Given an additional range adaptor closure object D, the expression C | D is well-formed and produces another range adaptor closure object

If I understand your codebase correctly the only types that your adaptor closure objects also consider as adaptor closure objects are those that inherit from ranges::detail::pipeable_base.

This seams very difficult to deal with in a generic context. In absence of some global trait that can be specialised to mark adaptor types as such, the only version that worked for us, is to have all our adaptors overload a "composing" operator| for any types and for lhs and rhs (which causes difficulties of its own). [in addition to the non-composing range-handling operator|].

Ideally one would have std::is_range_adaptor_closure that you can specialise for your own type and either

  1. a free function operator| in the standard library for two such types that implements the composing; or
  2. the formal requirement that each range adaptor closure object be responsible for facilitating the composing with other such objects on the left side (or the right, but it should be specified to prevent ambiguous overloads)
ericniebler commented 5 years ago

An is_range_adaptor_closure trait would be nice to have.