[fpc-devel] Inconsistency in generics ?
lazarus at mfriebe.de
Fri Mar 3 15:01:04 CET 2023
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?
generic TGen<B> = class
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?
More information about the fpc-devel