<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Martin Frb via fpc-devel <<a href="mailto:fpc-devel@lists.freepascal.org" target="_blank" rel="noreferrer">fpc-devel@lists.freepascal.org</a>> schrieb am Fr., 3. März 2023, 12:55:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To me the below behaviour appears inconsistent.<br>
But before I file a bug, I want to double check, if maybe this is <br>
intention....<br>
<br>
Tested with 3.2.3  and 3.3.1<br>
<br>
Apparently<br>
- when the generic TGen is compiled, it does check if a type "TRec1" and <br>
"TRec2" is in scope at all.<br>
- it verifies that the generic itself compiles with that type<br>
- **but** then it allows that type to be replaced by another, if the <br>
specialized param contains such another type<br>
<br>
So if the specialized class, can have a type of it's own choosing for <br>
"TRec1" then why insist that a random other type of that name exists <br>
when the generic is declared.<br>
(And why reject "TRec2" as it too could be available at the time of <br>
specialization?)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div></div>