On 03/03/2023 14:29, Sven Barth via fpc-devel wrote:
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.
I got to this only while generating code to feed code-tools. So it's not
that I need it to be either way.
I understand there is a set of rules to explain it all (or most of it,
see "why" in code below).
But the result of those rules are somewhat "interesting"
It still feels strange....
It leads to "TRec1" being checked as something that it is not.
If the "specialize" allows TRec1 to be something else (and something
completely unrelated), then why does the generic check at all, that the
non-specialized code compiles against the one seen by the generic?
type
generic TGen<B> = class
procedure x;
end;
procedure TGen.x;
begin
B.x := 1; // works, even so the compiler has no info what B might
be (only that there is a name B)
// B.y(); // then again, does not work - why?
end;
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
