[fpc-devel] New feature discussion: for-in loop

[Martin]

Paul Ishenin wrote:
> Marco van de Voort wrote:
>> btw the earlier discussions about D2005+ functionality are archived at:
>>
>> http://www.stack.nl/~marcov/delphilater.txt
>>
>> I wanted to use this for an article, so the log are sligtly processed 
>> and
>> annotated.
>
> There is no much threre regards 'for-in'. I would like if you/somebody 
> else improve the current wiki 'for-in' article with your/somebody else 
> ideas.

The more I think about the more headaches it causes. Now I agree it 
needs to be done for delphi mode

If you do it for objpas/fpc mode it starts the question how far? Let's 
start with the simpliest for-in, and add each next step, and someone 
please tell me how far for-in shopuld go...
- for in for ranges [1..10], sets and enum types
- for arrays
- for strings
- for any object via iterator
- with reverse iteration...
 => Now reverse iteration can be done by a different iterator class,
- with filtered iteration...
 => what if you want to iterate through all entries of a list 
(stringlist) that have "length(entry) > 10" ?
   To do that (and specify differnt filters) you need to instantiate the 
iterator yourself, and set the values for the filter condition.
   But if you pass an instantiated iterator to for-in => should it still 
auto destroy it? And if not, you are back to "while (iterator)"

I don't think the last one is really desired... but where to draw the line?
Except for the last one: does iterator have to be a class or object at all?

I hadn't had time to think it all through => so I just throw some half 
finish thoughts in... maybe ....

It could be done as an overloaded operator => a function with an 
additional var-param  that is used for the state
  operator ITR = function IterateFoo(FooValue: TFooType;  ItrState: 
Pointer; out ItrNoMoreValues: Boolean): FooEntryType

for-in would call it the first time with a nil for ItrState => the 
function can then store a number, or create a StateObject, or whatever 
to remember it;s position.
For all other calls to the function, the param would be passed back in, 
as it was set on the previous call. Just as if it was a local variable 
in the calling code)
- It has a serious flaw in this version => if the loop is aborted early 
"break", then there is no way to tell the iterator. If it was an object 
then it would just get destroyed. It would need the last param to be var 
as well, and be passed in true, for required stop
- And of course this would reduce the possibilities a lot, and be far 
less elegant. (but then again where in the above list should the line be 
drawn?)
- on the pro:
   - It is the simpliest solution. Some iterators do not need to be an 
object.
   - For Iterators that need to be an object, it can act as a wrapper 
and store it in pointer
   - "using" could still be done, but need to point to a function of 
this type
   - no hardcoded function/method names (see below)
   - compatible with how other operators are overloaded (as functions)

The problem I have with the iterator being an object is that it would 
currently end up with having certain method names (such as "next") 
hardcoded in the compiler => I dislike this idea. (actually "dislike" is 
understating it)
So if the iterator was to be an class/object, there would first be a 
need to introduce keywords or modifiers, that allow the programmer to 
mark the correct methods for the operation.

My 2 cent
Martin