[OT] foreach(scheme) (Was: Differentiate const flavors using CASE?)

[Daniel Keep]

kris wrote:
> Daniel Keep wrote:
>>
>> kris wrote:
>>
>>> janderson wrote:
>>>
>>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>>
>>>>>
>>>>> Yah :o). Speaking of foreach_reverse, probably it would be wise to
>>>>> lobby Walter to deprecate it in favor of foreach(reverse) (item ;
>>>>> collection) { ... }. The keyword(extra) syntax is definitely becoming
>>>>> a D signature syntax.
>>>>>
>>>>>
>>>>> Andrei
>>>>
>>>>
>>>> //Using your other suggestion:
>>>> foreach(reverse) (item ; collection) (item2 ; x->GetColection(b))
>>>> (item3 ; collection3)
>>>> {
>>>>
>>>> }
>>>>
>>>> Its starting to get hard and harder to read IMO.
>>>>
>>>> Although perhaps the reverse could be come sort of iterator mechanism.
>>>> You could define what order items are visited.  I mean, reverse would
>>>> not be a keyword at all and would exist in some library.  Although I'm
>>>> not sure how it would be implemented, and it may defeat the purpose of
>>>> foreach_reverse being optimal.
>>>>
>>>> Just a thought.
>>>
>>> shouldn't this perhaps be something like:
>>>
>>> foreach (item; collection) (item2; x->GetColection(b))(item3;
>>> collection3.reverse)
>>> {
>>>
>>> }
>>>
>>>
>>> Now you can select a direction on the each container?
>>>
>>> Naturally, this would avoid performing a copy of the content, and the
>>> basic approach is quite easy to handle via a struct containing an
>>> opApply(). It would open the door to alternate iteration approaches
>>> also, such as skipping entries, merging, or whatever.
>>>
>>> Tango does something vaguely like this for the text-iterators in
>>> tango.text.Util
>>
>>
>> What if collection3 is a 40 MB array?
>>
>> The nice thing about foreach_reverse is that it doesn't require any
>> transformations on the data.  
> 
> I didn't suggest transformation at all :) Merely a mean of satisfying
> opApply that happens to go backwards instead (or some other pattern).

I realise this, but my point was that 'reverse' on an array *actually*
reverses the array.  If we have it return a struct that implements
opApply, then people are going to wonder why 'arr.reverse' doesn't
reverse the array.

At least with operator overloads, we can keep them separate.

That said, maybe something along the lines of .iterReverse or somesuch
would work... but then, it would be nice to not have to stuff around
with all these structs :P  *dreams of having Python-style generators*

The other thing to think about is that we shouldn't have to use a member
function of a structure when the compiler should *know* how to go
backwards over a silly little array.

But then, maybe that's just me :)

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/