New linked list

[Sean Kelly]

Walter Bright wrote:
> Sean Kelly wrote:
>> Walter Bright wrote:
>>> Sean Kelly wrote:
>>>> Very cool.  One thing... does this work:
>>>>
>>>>     foreach( Person p; per.each )
>>>>     {
>>>>         if( p.age > 50 )
>>>>             p.listRemove();
>>>>     }
>>>>
>>>> ie. can you remove elements within a foreach?
>>>
>>> It's undefined behavior. foreach is entitled to assume that the 
>>> aggregate is a loop invariant, although the contents of the 
>>> aggregate's elements can change. This precludes things like resizing 
>>> an array inside a foreach, etc.
>>
>> Even for a class that defines an opApply?
> 
> Yes. The idea is to apply uniform semantics.

Understandable.

>> What about an alternate syntax:
>>
>>     foreach( Person p; personList )
>>     {
>>         if( p.age > 50 )
>>             personList.remove( p );
>>     }
>>
>> Assuming the list code supports this operation (say the 'next' pointer 
>> isn't set to null when p is removed, and thus the iteration should 
>> continue without any problems), is the behavior still undefined?
> 
> Yes.

*sigh*  I can see the reason for this, but it dramatically reduces the 
utility of foreach for me, as it's a very common idiom to want to remove 
elements during an iteration.  In fact, I already use this technique 
quite a bit in Thread and ThreadGroup.  That aside, does this 
restriction also exist for processing AA elements?  I ask because this 
is done on a dynamically allocated list of references rather than 
against the AA itself, though I suppose that's implementation defined.

>> If so, I assume it would be okay to store a list of 'removed' items 
>> until the iteration ends and them remove them all at once?
> 
> Yes.

Thanks.  Assuming I did this, would it be technically legal to destroy 
this list after the iteration ends but before opApply returns? 
Otherwise, I'm not entirely certain how to go about processing the removals.


Sean