Martin Frb via fpc-devel <fpc-devel@lists.freepascal.org> schrieb am Fr., 3. März 2023, 12:55:
> To me the below behaviour appears inconsistent. > But before I file a bug, I want to double check, if maybe this is > intention.... > > Tested with 3.2.3 and 3.3.1 > > Apparently > - when the generic TGen is compiled, it does check if a type "TRec1" and > "TRec2" is in scope at all. > - it verifies that the generic itself compiles with that type > - **but** then it allows that type to be replaced by another, if the > specialized param contains such another type > > So if the specialized class, can have a type of it's own choosing for > "TRec1" then why insist that a random other type of that name exists > when the generic is declared. > (And why reject "TRec2" as it too could be available at the time of > specialization?) > All identifiers must be known when declaring a generic. In this case Trec1 is known thanks to the global type. Trec2 is not known (neither in its parent (at declaration time TBase1) nor globally) , so that will fail. When you specialize with TBase2 you change the parent thus a completely new scoping situation arises and Trec1 will no longer be the global Trec1, but that of TBase2. Considering how generics are implemented this is both as expected and as designed. Not to mention that using the generic parameter as parent is *not* officially considered a feature. It's simply not forbidden. Regards, Sven
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel