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

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.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140303/fabd5499/attachment.html>

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/llvm-dev/attachments/20140303/8ba413e8/attachment.html>

On Mar 3, 2014, at 12:04 AM, Chandler Carruth <chandlerc at google.com>
wrote:
>> 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
It's getting the range though, just like Function::getArgumentList() returns
the argument list.
> 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.
That's a very objective-c thing to do :-), they use the pattern foo() and
setFoo() for the getter and setter, respectively (and the naming is baked into
the property model).  I don't feel strongly against it, but we pretty
consistently use the Java style 'get' prefix everywhere else.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140303/2f17c2b9/attachment.html>

On Mon, Mar 3, 2014 at 3: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.
>
My 2c is that we should choose a naming convention that yields a completely
consistent way to mechanically transform foo_begin/foo_end to the range
equivalent. Even just the plural has the usual natural language exceptions.
My vote is for foo_begin/foo_end/foo_range.

-- Sean Silva

>
> -Chris
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140304/e7faef69/attachment.html>