Super-dee-duper D features

[Andrei Alexandrescu (See Website For Email)]

renoX wrote:
> Andrei Alexandrescu (See Website For Email) a écrit :
>> renoX wrote:
>>> Andrei Alexandrescu (See Website For Email) a écrit :
>>>> BTW, D might soon have simultaneous iteration that will blow away 
>>>> all conventional languages:
>>>>
>>>> foreach (i ; coll1) (j ; coll2)
>>>> {
>>>>   ... use i and j ...
>>>> }
>>>> continue foreach (i)
>>>> {
>>>>   ... coll2 finished; use i ...
>>>> }
>>>> continue foreach (j)
>>>> {
>>>>   ... coll1 finished; use j ...
>>>> }
>>>>
>>>> Best languages out there are at best ho-hum when it comes about 
>>>> iterating through simultaneous streams. Most lose their elegant 
>>>> iteration statement entirely and come with something that looks like 
>>>> an old hooker early in the morning.
>>>
>>> At first, I really didn't like the 'continue foreach', then 
>>> afterwards I got used to it, I wonder if this is really such a 
>>> requested feature though, what's wrong with the good old 'for' or 
>>> 'while' for the complex case?
>>
>> Absolutely nothing's wrong. The same argument, however, could be 
>> formulated to render foreach redundant. We have for, don't we.
>>
>> The thing is foreach is terse and elegant and has a functional flavor 
>> that gives it safety and power that for doesn't have.
> 
> I wouldn't call 'functional flavored' something with such an 'hidden 
> state' stored in i, but that's just me.

My definition of "foreach (i ; c) S" is: bind i in turn to each element 
of c, and evaluate S. That's very functional. The definition really 
reminds much more of map and fold, than of "for (s; e1; e2) S". And 
let's not forget that all functional programs sneak state in their 
arguments - or a monad :o).

> And I have a question for the safety: what is supposed to happen if the 
> programmer modifies coll1 between the foreach(i ; coll1) and continue 
> foreach?

That's a good question. Currently the behavior is undefined. The 
behavior that Walter is thinking of implementing is to render it 
implementation-defined, but never undefined (as in thrashing random 
memory). All that needs to be done is disallow in-place shrinking of 
containers. The garbage collector will take care of the rest.

> Adding or removing value in the collection before the continue foreach?

See above.

> Just being curious, I would imagine that this is just forbidden.

That's what it is today - it's formally forbidden. After Walter 
eliminates in-place shrinking, it will be safe, and interestingly, there 
will never be a need for bounds checking.


Andrei