View mode: basic / threaded / horizontal-split · Log in · Help
July 12, 2012
Re: opApply not called for foeach(container)
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.
July 12, 2012
Re: opApply not called for foeach(container)
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
July 13, 2012
Re: opApply not called for foeach(container)
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.
July 13, 2012
Re: opApply not called for foeach(container)
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
July 15, 2012
Re: opApply not called for foeach(container)
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
July 16, 2012
Re: opApply not called for foeach(container)
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.
July 16, 2012
Re: opApply not called for foeach(container)
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
July 16, 2012
Re: opApply not called for foeach(container)
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
July 16, 2012
Re: opApply not called for foeach(container)
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
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home