[PATCH] D134076: RFC - [ADT] Ranges pipe syntax support + SFINAE

[James Player via Phabricator via llvm-commits]

jplayer-nv added a comment.

In D134076#3797962 <https://reviews.llvm.org/D134076#3797962>, @dblaikie wrote:

> My gut reaction is that this is quite a lot of API surface area to add without current or near-future planned usage.
>
> Any chance you're interested in proposing this as part of a patch series to at least migrate some of the existing iterator-adaptor or custom algorithms to this usage? (@kazu - maybe this'd be of some interest to you too?)

I'd be happy to break this down into bite-sized chunks.  Is discourse the right place to iterate on the details of such a patch series?  I can start with the ability to default construct and copy-assign existing iterators which carry a callable.

> & I seem to recall some discussion about compile-time performance problems with view heavy code? Does anyone have any info on that?

I'm seeing complaints regarding compile-time effect of including `<algorithm>`, is there anything you recall reading which was more specific to usage overhead?

In D134076#3798329 <https://reviews.llvm.org/D134076#3798329>, @kazu wrote:

> The reason for my lazy/passive approach is as follows.  I do like the expressiveness of the views with the "pipe" operator `|`, but it's mostly syntactic sugar that doesn't significantly reduce the token count -- `A | B | C` v.s. `C(B(A))`.

Agreed... it's an ergonomics improvement.  My eyes start glassing over with the functional syntax if you start passing parameters:

  reverse(drop(take(MyRange, 2), 4))

vs

  MyRange | take(2) | drop(4) | reverse

I'm happy to upstream in small bites if this is desired, or we can stop short of the pipe syntax if it's deemed a nuisance.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134076/new/

https://reviews.llvm.org/D134076