[fpc-pascal] fcl-passrc errors

[Sven Barth]

Am 13.10.2019 um 23:19 schrieb Ryan Joseph:
>
>> On Oct 13, 2019, at 11:11 AM, Sven Barth via fpc-pascal <fpc-pascal at lists.freepascal.org> wrote:
>>
>> Then specialize the list with the correct type.
>>
>> This issue *will* be fixed and is not up to discussion.
>>
> Here’s some code from the parser today. TFPList is being used because it’s a generic storage for various different kinds of classes.
>
>    public
>      Declarations: TFPList; // list of TPasElement
>      // Declarations contains all the following:
>      Attributes, // TPasAttributes
>      Classes,    // TPasClassType, TPasRecordType
>      Consts,     // TPasConst
>      ExportSymbols,// TPasExportSymbol
>      Functions,  // TPasProcedure
>      Properties, // TPasProperty
>      ResStrings, // TPasResString
>      Types,      // TPasType, except TPasClassType, TPasRecordType
>      Variables   // TPasVariable, not descendants
>        : TFPList;
>
> What do I do when I want to iterate over this now? I know that these types all descend from TPasElement so I want to use that, but no, the compiler complains I *must* use a pointer for the iterator. Why can’t I as the programmer tell the for loop I know what the enumerator is going to return?

Because the iterator returns a Pointer and not whatever you think it 
might return. If you know it's something else, you cast that inside the 
loop.

>
> var
>    element: TPasElement;
> begin
>    // ERROR!
>    for element in module.InterfaceSection.Functions do
>      begin
>      end;
>
>
> I guess we’re supposed to just do our typecasts inside the loop now but how is this any better? Sorry I’m really not getting this.
It's not about better or not, it's about correct: The for-in-loop 
expects a variable, not an expression, just like the normal for-loop 
does. And as this behavior is accidental it could just as well be that 
this breaks behind the scene. For example if we should optimize for-in 
some time in the future. Or it might trigger some runtime checks.

Regards,
Sven