[fpc-devel] Inconsistency in generics ?

[Sven Barth]

Martin Frb via fpc-devel <fpc-devel at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20230303/b470de1b/attachment.htm>