On Thursday, 12 July 2012 at 21:18:21 UTC, Steven Schveighoffer wrote:
>
> If opSlice is to be used, this is how it should go (in order of precedence):
>
> 1. if aggr has opApply or opApplyReverse, use it.
>
> 2. if aggr has opSlice, and the result of aggr.opSlice() has opApply or opApplyReverse, use it.
>
> 3. if aggr has opSlice, and the result of aggr.opSlice() has empty/front/popfront, use it as in your 2a above.
>
> 4. if aggr has empty/front/popFront, use it as in your 2b above.
>
> 5. static or dynamic array.
>
> I should also note that the existence of opApply should not preclude later possibilities if that opApply can't compile for the given foreach parameters.
>
> -Steve

4.1:Make copy first.

On Thu, 12 Jul 2012 17:35:23 -0400, monarch_dodra <monarch_dodra@gmail.com> wrote:

> On Thursday, 12 July 2012 at 21:18:21 UTC, Steven Schveighoffer wrote:
>>
>> If opSlice is to be used, this is how it should go (in order of precedence):
>>
>> 1. if aggr has opApply or opApplyReverse, use it.
>>
>> 2. if aggr has opSlice, and the result of aggr.opSlice() has opApply or opApplyReverse, use it.
>>
>> 3. if aggr has opSlice, and the result of aggr.opSlice() has empty/front/popfront, use it as in your 2a above.
>>
>> 4. if aggr has empty/front/popFront, use it as in your 2b above.
>>
>> 5. static or dynamic array.
>>
>> I should also note that the existence of opApply should not preclude later possibilities if that opApply can't compile for the given foreach parameters.
>>
>> -Steve
>
> 4.1:Make copy first.

Kenji's 2b does do that:


  for (auto __r = aggr;  // If aggr is copyable, saves the original range.
      !__r.empty;
      __r.popFront()) { auto e = __r.front; ...body... }


-Steve

On Thursday, 12 July 2012 at 22:02:19 UTC, Steven Schveighoffer wrote:
> On Thu, 12 Jul 2012 17:35:23 -0400, monarch_dodra <monarch_dodra@gmail.com> wrote:
>
>> On Thursday, 12 July 2012 at 21:18:21 UTC, Steven Schveighoffer wrote:
>>>
>>> If opSlice is to be used, this is how it should go (in order of precedence):
>>>
>>> 1. if aggr has opApply or opApplyReverse, use it.
>>>
>>> 2. if aggr has opSlice, and the result of aggr.opSlice() has opApply or opApplyReverse, use it.
>>>
>>> 3. if aggr has opSlice, and the result of aggr.opSlice() has empty/front/popfront, use it as in your 2a above.
>>>
>>> 4. if aggr has empty/front/popFront, use it as in your 2b above.
>>>
>>> 5. static or dynamic array.
>>>
>>> I should also note that the existence of opApply should not preclude later possibilities if that opApply can't compile for the given foreach parameters.
>>>
>>> -Steve
>>
>> 4.1:Make copy first.
>
> Kenji's 2b does do that:
>
>
>   for (auto __r = aggr;  // If aggr is copyable, saves the original range.
>       !__r.empty;
>       __r.popFront()) { auto e = __r.front; ...body... }
>
>
> -Steve

Oh, right "use it as in _your_ 2b above". Didn't get what you meant at first.

About the if "opApply can't compile": Do you mean:
a) If there is no matching opApply function?
b) Or if there is an actual error in the body of opApply?
I think you meant a) ?

I think your 1. and 2. should instead read:
1. if aggr has a matching opApply or opApplyReverse, use it.
2. if aggr has opSlice, and the result of aggr.opSlice() has a matching opApply or opApplyReverse, use it.

On Fri, 13 Jul 2012 02:20:45 -0400, monarch_dodra <monarch_dodra@gmail.com> wrote:

> On Thursday, 12 July 2012 at 22:02:19 UTC, Steven Schveighoffer wrote:
>> On Thu, 12 Jul 2012 17:35:23 -0400, monarch_dodra <monarch_dodra@gmail.com> wrote:
>>
>>> On Thursday, 12 July 2012 at 21:18:21 UTC, Steven Schveighoffer wrote:
>>>>
>>>> If opSlice is to be used, this is how it should go (in order of precedence):
>>>>
>>>> 1. if aggr has opApply or opApplyReverse, use it.
>>>>
>>>> 2. if aggr has opSlice, and the result of aggr.opSlice() has opApply or opApplyReverse, use it.
>>>>
>>>> 3. if aggr has opSlice, and the result of aggr.opSlice() has empty/front/popfront, use it as in your 2a above.
>>>>
>>>> 4. if aggr has empty/front/popFront, use it as in your 2b above.
>>>>
>>>> 5. static or dynamic array.
>>>>
>>>> I should also note that the existence of opApply should not preclude later possibilities if that opApply can't compile for the given foreach parameters.
>>>>
>>>> -Steve
>>>
>>> 4.1:Make copy first.
>>
>> Kenji's 2b does do that:
>>
>>
>>   for (auto __r = aggr;  // If aggr is copyable, saves the original range.
>>       !__r.empty;
>>       __r.popFront()) { auto e = __r.front; ...body... }
>>
>>
>> -Steve
>
> Oh, right "use it as in _your_ 2b above". Didn't get what you meant at first.

hehe, sorry.  Should have said Kenji's...

>
> About the if "opApply can't compile": Do you mean:
> a) If there is no matching opApply function?
> b) Or if there is an actual error in the body of opApply?
> I think you meant a) ?
>
> I think your 1. and 2. should instead read:
> 1. if aggr has a matching opApply or opApplyReverse, use it.
> 2. if aggr has opSlice, and the result of aggr.opSlice() has a matching opApply or opApplyReverse, use it.

Yes, I meant matching.  Meaning if I define front to return int, and opApply takes a delegate for a float, then foreach(int x; aggr) should use the range primitives, foreach(float x; aggr) should use opApply.

-Steve

On Thursday, July 12, 2012 16:50:22 monarch_dodra wrote:
> On Wednesday, 11 July 2012 at 20:24:42 UTC, Jonathan M Davis
> 
> wrote:
> > The problem is that it's essentially spread out across 3
> > places: the online
> > spec, TDPL, and the compiler.
> > 
> > ...
> > 
> > - Jonathan M Davis
> 
> The problem is not only the documentation, it's getting authoritative answers. I see some strange behaviors, and I can't for the life of find out if it is a bug in the documentation/compiler, or a pitfall/misunderstanding.
> 
> What is your take on the issue at hand? Bug or Pitfall?

My take on it is that you should either go with ranges or opApply and try to avoid mixing them. Ideally, we wouldn't even need opApply anymore, but ranges can't quite do everything that it can.

- Jonathan m Davis

On Sunday, 15 July 2012 at 20:01:35 UTC, Jonathan M Davis wrote:
> Ideally, we wouldn't even need opApply anymore

AFAIT, that's impossible.

Not because of D, but because of other stuff.

Lots of functions require callbacks for enumeration (e.g. EnumChildWindows in Windows); it's simply impossible to wrap them through something that doesn't take control away from the caller.

On Monday, 16 July 2012 at 06:27:13 UTC, Mehrdad wrote:
> On Sunday, 15 July 2012 at 20:01:35 UTC, Jonathan M Davis wrote:
>> Ideally, we wouldn't even need opApply anymore
>
> AFAIT, that's impossible.
>
> Not because of D […]

How else woud you implement things like parallel foreach, …?

David

On Monday, July 16, 2012 09:47:50 David Nadlinger wrote:
> On Monday, 16 July 2012 at 06:27:13 UTC, Mehrdad wrote:
> > On Sunday, 15 July 2012 at 20:01:35 UTC, Jonathan M Davis wrote:
> >> Ideally, we wouldn't even need opApply anymore
> > 
> > AFAIT, that's impossible.
> > 
> > Not because of D […]
> 
> How else woud you implement things like parallel foreach, …?

As I said, _ideally_ we wouldn't need opApply, but ranges fail to be able to work in every use case that opApply does. As great as ranges are, there _are_ some cases where ranges are insufficient. So, we still have opApply.

- Jonathan M Davis

On Monday, 16 July 2012 at 08:13:49 UTC, Jonathan M Davis wrote:
> On Monday, July 16, 2012 09:47:50 David Nadlinger wrote:
>> On Monday, 16 July 2012 at 06:27:13 UTC, Mehrdad wrote:
>> > AFAIT, that's impossible.
>> > 
>> > Not because of D […]
>> 
>> How else woud you implement things like parallel foreach, …?
>
> As I said, _ideally_ we wouldn't need opApply, but ranges fail to be able to
> work in every use case that opApply does. As great as ranges are, there _are_
> some cases where ranges are insufficient. So, we still have opApply.

My comment was specifically meant in reply to Mehrdad's »Not because of D« statement.

David