Super-dee-duper D features

[Bill Baxter]

Andrei Alexandrescu (See Website For Email) wrote:
> Bill Baxter wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> Frits van Bommel wrote:
>>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>>> Sean Kelly wrote:
>>>>>> What about:
>>>>>>
>>>>>>     foreach (i ; coll1) (j ; coll2)
>>>>>>     {
>>>>>>         if( true )
>>>>>>             continue i;
>>>>>>     }
>>>>>>
>>>>>> ie. allow 'continue' to accept labels to specify which collection 
>>>>>> is iterated.  A 'continue' without labels would iterate both.
>>>>>
>>>>> I think that's a great idea, except that "continue to label" has 
>>>>> the same syntax: 
>>>>> http://digitalmars.com/d/statement.html#ContinueStatement
>>>>
>>>> Does that really matter? The compiler knows whether 'i' is a label 
>>>> or a loop variable (presumably it can't be both at the same time?) 
>>>> so it knows what to do. Note that the current "continue to label" 
>>>> wouldn't help here since there's only one statement for a "double" 
>>>> iteration. So the most natural way to specify which loop to continue 
>>>> would be to specify the variable.
>>>
>>> That's a good point, but changing names could complicate maintenance.
>>>
>>>> By the way, would the new loop syntax allow more than two 
>>>> collections to be simultaneously iterated?
>>>> That would indicate the need for a "continue i, j" as well, to 
>>>> specify multiple variables.
>>>> On the other hand, with your proposed "continue foreach" clauses 
>>>> after the main loop that would also require an exponential number of 
>>>> those clauses for different sets of collections running out if you 
>>>> want to handle all cases...
>>>
>>> That is correct. But it's not a real issue for a simple reason: the 
>>> user would have to write the code. If they need to handle all cases, 
>>> well, that's what they need to do one way or another. The foreach 
>>> statement does not add anything to the equation.
>>
>> Yes it does make a difference.  In the iterator case I can use all of 
>> D to determine how to resolve the fact that there are different 
>> lengths of data.  In the continue foreach scenario, I have only one 
>> recourse -- write all the continute foreach's I need.
>>
>> Consider I want to add N vectors of potentially different lengths 
>> together.  With the right iterator solution I could get away with just:
>>
>> foreach( iters,xs; multi_iter(a,b,c,d,e) )
>>   foreach(it; iters)
>>     if (!it.end) out[j] += xs[i];
>>
>> With "continue foreach" I'm just going to give up and write a for loop.
> 
> That is correct. It's a limitation of "continue foreach" exactly because
> it ties validity with syntactic scoping: the result gives a stronger
> guarantee, but is inherently more restrictive.

Ok so it's like more of the same foreach business.  If it works for you, 
great.  If not, sorry.  Go find another way to do it.  Meh.

> I'll add that probably adding multiple vectors of different lengths 
> would loop the other way around :o).

Yeh, fair enough.  :-)
Let's say I want to print out the data columnwise instead.

foreach( iterset; multi_iter(a,b,c,d,e) ) {
   foreach(i,it; iterset)
     writef("%s ", it.end ? "<no data>" : it.val);
   writefln();
}

I will give you though, that it would be more difficult to make that as 
efficient as the more restricted solution you're talking about.

--bb