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

[Duncan Exon Smith]

> On Mar 4, 2014, at 22:25, Chandler Carruth <chandlerc at google.com> wrote:
> 
> 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
> 

I'm in for beers, anyway!

>> 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.
> 

Admittedly, I'm coming in with a Boost bias, having used that range library for years. 

> 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)))"

This is interesting.  I hadn't considered r-value references with ranges.  Is there a problem with supporting both semantics with the same names?

    template <class Range> Range reverse(Range &&R);
    template <class Range> void reverse(Range &R);

> 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.

You're right, it needs to somehow be clear.  I think one reasonable rule is "past participle" means adaptor, while "present tense" means algorithm.  (That's why "reversed" makes some sense to me.)  By that rule, I'd say reverse, filter and rotate are algorithms (mutating the input), but reversed, filtered and rotated are adaptors (providing a mutated view of the input).  If we're consistent it'll be clear.

> 
> 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.

Agreed. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140304/18c9b0c9/attachment.html>