[fpc-devel] Inconsistency in generics ?

[Martin Frb]

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;