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

[Marc Weustink]

Michael Van Canneyt wrote:
> 
> On Tue, 20 Oct 2009, Paul Ishenin wrote:
> 
>> Michael Van Canneyt wrote:
>>
>>> At least one of the reasons we never did implement for-in is the 
>>> absolutely
>>> horrible and totally wrong idea to use classes/interfaces for this, 
>>> to which
>>> I seriously objected.
>>
>> Reading this I conclude you are against 'for-in' implementation in fpc.
> 
> No.
> 
>>> I can understand
>>>   for y in enumerated do
>>> or
>>>   For y in set do
>>> or
>>>   For Y in range do
>>> Because this seems a natural extension of loops to enumerates (and even
>>> then) But not ever the class-based one.
>>
>> So you are not against it but you want to allow them only for the base 
>> types?
> 
> Yes.

IMO too

>> I hope you understand that ppl will use them for classes anyway?
> 
> Those people should be re-educated to use iterators.

Exactly. This all start to look a bit to much like the VB iterator 
magic. Where some under the hood functions (names) were used for 
iterating. If you didn't declare a container with the right function 
names you couldn't loop.

>> var
>>  P: Pointer;
>> begin
>>  for P in GetComponents(Component) do
>>    TComponent(P).DoSomething;
>> end;
>>
>> And what is so special in the class type?
> 
> First:
> For a for loop, you are guaranteed that the loop logic behaves correctly.
> A loop is equivalent to the following:
> 
> I:=StartValue;
> E:=EndValue;
> While I<=EndValue do
>   begin
>   // loop stuff
>   Inc(I);
>   end;
> 
> And you cannot change I manually during the loop.
> 
> You don't know this with an iterator since you depend on the implementation
> of the iterator. The loop could loop forever then...
> 
> Secondly:
> You promote a certain class/interface to a language feature. The 
> compiler then depends on the presence of a certain class with some 
> 'known' methods in the RTL.
> 
> Both points are simply wrong from a language point of view.

Exactly. You extend a language construct with something defined with 
that language (i don't know how to explain better)

> It is bad enough that the second point is already so for interfaces and 
> even TObject, (a very serious design flaw by Borland) but extending this 
> even further to include actual language features such as the for loop is 
> 2 bridges too far
> as far as I'm concerned.
> 
> Especially when you can have perfectly the same functionality with 
> iterators.

I can see a use for using iterators in a for loop, however they should 
be declared with some keyword.

Something like

type
   TListIterator = iterator(TList, init_func, next_func, check_func)
     function init_func: Boolean;
     function next_func: <element type>
     function check_func: Boolean;
   end;

begin
   for element in list using TListIterator do...

IMO this is more pascal than using some interface or predefined function 
names.

Marc