[LLVMdev] [cfe-dev] C++11 reverse iterators (was C++11 is here)

[Chandler Carruth]

I suspect that at a certain point (soon) those of us who feel strongly
about this should sit down if possible and hash this out either over lunch,
beers, or a whiteboard. =D

On Tue, Mar 4, 2014 at 9:26 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

> I agree.  Algorithms should be verbs.
>
> However, I disagree that range adaptors are algorithms.
>
> “reverse” sounds like an algorithm.  Consider, from the STL:
>
>     template <class Iterator> void reverse(Iterator F, Iterator L);
>
> I’d expect a range version of the algorithm to look like this:
>
>     template <class Range> void reverse(Range &R) {
>       reverse(std::begin(R), std::end(R));
>     }
>
> On the other hand, “reversed” sounds like an accessor, and I’d expect it
> to look something like this:
>

I understand the point you're trying to make here, and how you would
implement it, however I'm not persuaded this is the right design.

First, while an in-place approach to the interface of range algorithms is
one possibility, it has a fatal flaw: it is not composable. I want to be
able to write something equivalent to "x = reverse(sort(slice(std::move(x),
1, 10)))" because this allows us to factor apart the different aspects of
using ranges. It addresses the "<foo>_if" composition problem, the
"<foo>_n" composition problem, etc. The solution requires us to bring value
semantics to algorithms, what I think would be the best result of ranges in
C++.

Second, I really don't want two different patterns, because I find it very
hard to tell what is an algorithm and what isn't. Maybe "sliced" clearly
isn't an algorithm, and "sort" clearly is, but "reversed" starts to blur
the line. What about rotate? I have heard many argue that filter should be
an accessor. If sort is an algorithm, than surely partition is. But
partition is just the same as filter! I think it is all simpler if these
all follow the same fundamental pattern.

Third, this is *exactly* what I mean that we don't yet know what ranges
look like in C++. Whatever we end up with, I think we should be prepared to
change it based on experience and based on the discussions that go on in
the committee. My hope is that we can try out some of these approaches and,
if they work, also contribute to that discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140304/385cd83d/attachment.html>