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

[Chandler Carruth]

On Mon, Mar 3, 2014 at 12:01 AM, Chris Lattner <sabre at nondot.org> wrote:

> On Mar 2, 2014, at 10:47 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
>
> I'm not aware of the prior art or standards are here, but I think that a
>>>> global reverse() adapter is the way to go.  Likewise, we should have a
>>>> standard "enumerate()" adaptor like python.
>>>
>>>
>>> I definitely prefer the global adaptor pattern.  As for prior art, I had
>>> played with it a bit, and came up with
>>> https://gist.github.com/compnerd/5694186 a while back.
>>>
>>
>> Yea, there is a pretty strong move toward range adaptors. If possible,
>> I'm going to work on contributing a basic selection of them to LLVM's ADT
>> specifically to address the immediate needs of range-based for loops.
>>
>>
>> Sounds good.  We also have to decide what to do with
>> Function::arg_begin() for example (and all the other secondary ranges
>> hanging off IR and other things).  IMO, "for (auto &arg :
>> F.getArguments())" makes the most sense.
>>
>
> I was actually going to check in this, but I can post it for review if
> folks are worried.
>
> My plan was to provide an implementation of std::iterator_range<T> and
> then provide 'F.arguments()' which returns it.
>
>
> Nice.  What's the logic behind .arguments() vs .getArguments()?  I don't
> have a strong opinion either way, but there should be rationale.
>

In the best case 'get' doesn't really add any meaning, and in the worst
case it is actively misleading

For example, you might iterate over operands, and assign through the
iterator to mutate them.

Really, these operate as range-views over some sequence. It seems
particularly easy to teach foo_begin(), foo_end() -> foos() as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140303/8ba413e8/attachment.html>