Modern For Loop question

[Peter H]

The error message is wrong, because it says: "expected a pointer and got a char".

The error refers to the variable p as indicated by the column number. p is a pointer type, but the in s enumeration returns a char type.

Exactly. Before the compiler can expect any type, it must evaluate the enumeration. This is, where the value comes from. Therefore it expects a char as assignement target, but it got a pointer, and therefore the message is not correct.
Or:
It gets a pointer and then evaluates the enumeration and gets a char but expected a pointer. Then the message is correct.
Maybe its not wrong, but unclear or not properly explained somewhere. 
Ok, I got it. the compiler obviously evaluates values strictly from left to right in the lexical analysis of the expression. This is the opposite flow of execution and I think in the flow of execution. I am not a lexical analyzer.  In this case the message is correct and I am wrong.

[ccrause]

Ok, I got it. the compiler obviously evaluates values strictly from left to right in the lexical analysis of the expression. This is the opposite flow of execution and I think in the flow of execution. I am not a lexical analyzer.  In this case the message is correct and I am wrong.

My view is that the logical error the compiler encountered is an incompatibility between the left and right sides of an assignment.  Whether the left side is wrong, or the right side, is not clear from the evaluation of this specific expression.  So in my opinion there are three potential error messages that are equivalent in reporting the error:
1. The whole expression is an error (for..in expression cannot generate an assignable value for p from s)
2. The left is incompatible with the right (p is not assignable from s)
3. The right is incompatible with the left (s is not assignable to p)

The compiler just need to identify which version it picked for reporting the error, in your example the text position flagged indicate that the error message is type 3.

[bytebites]

Code: Pascal  [Select][+][-]

1. s2:  Ts;   // Initialisation to Nil results in compile error here

Does not, it works correctly.

[Peter H]

Code: Pascal  [Select][+][-]

1. s2:  Ts;   // Initialisation to Nil results in compile error here

Does not, it works correctly.

Yes I had a typo, now this works.
However the error message is still rather dubios.
It says: "Expected Boolean got Char" and the cursor is at pos 5 where a boolean is.
Should the specialists decide, if this is intentional and correct.
Normally the cursor should be at the error position.

Then my way to read is correct, if there is type inference.
I removed delphi, so I cant test it, but in Delphi this should be possible:
for var c in arr do; and the type of c is automatically determined, and if they do it really clever, c is an implicit reference variable.


 

[kupferstecher]

And a construct like the below would be very helpful for save programming (Feature request ;-)

Code: Pascal  [Select][+][-]

1. for ii with someElement in SomeArray
2. do someElement.index:= ii;

Can you provide a practical example of what you are sort of requesting here?

I'm not seeing or understanding the desired use cases.

The integer variable would automatically run from zero until the loop is through, so this would be especially for arrays and lists. I just looked through my sources, there are not many examples when I need the iterator while looping through an array/list and these are not very significant examples. But still sometimes I need it.

An example would be printing a list with line numbers. (Perhaps still not very convincing:)

Instead of

Code: Pascal  [Select][+][-]

1. for ii:= 0 to SomeList.Count-1 do
2. do  Writeln(IntToStr(ii)+TListItem(SomeList[ii]).name);

it would be

Code: Pascal  [Select][+][-]

1. for ii with Pointer(ListItem) in SomeList
2. do Writeln(IntToStr(ii)+ListItem.name);

Code: Pascal  [Select][+][-]

1. var
2.   ii: Integer;
3.   SomeList:TList; //Contains elements of TListItem
4.   ListItem: TListItem;

Note, this is not about reduced writing, but to avoid loop bound mistakes.

Anyways, I remember there was an other reason why I stopped using for..in. In a multithreading application looping through a list in the standard way is thread save for read operations, with for..in it isn't any more, as the iterator is actually part of the list (At least I understand it like this). I know, an unprotected read access is something that shouldn't be done anyways, but I had some bad trouble with threads before, so I don't want to risk anything, there.