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@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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal