Let me first start by saying that generics is a bit out of my comfort-zone.
I know the basics and use them as such but it can drive a person insane trying to grasp what code is actually produced when using generics that inherited from other generics , combining generics with or without interfaces (which can also be made out of generics).
ok, so you say the class constraint will also accept record types?
No, not exactly (although i realize now, that it could perhaps be interpreted as such).
I meant the opposite, because of what happens when you use a template for base type (again, note that this should not be allowed). But indulging your train of thought, the compiler would have no clue how to handle things until it reaches the specialization.
consider the following:
type
TSomeRecord = record
SomeField: Integer;
end;
generic gTest2<T: TObject> = class(T)
end;
TG2a = specialize gTest2<TPersistent>;
TG2b = specialize gTest2<TSomeRecord>;
And compilations of TGB2b specialization fails, for obvious reasons.
I thought that the type checks for a generic were done in each specialization because it also cannot know the types of other variables which the compiler needs to know for the method bodies.
I am not going to pretend that i know how the compiler actually solves things, but as far as i understood the base type must be declared before.
Which brings us to the question whether or not the compilation of TG2a specialization should be at all possible or not (or if the compiler should already complain at the generic declaration).
Hence why i linked to the official type declaration for FPC generics, as that leaves room for such construct to be allowed (while Delphi seems to state things more explicitly in its documentation).
While Thaddy's solution also solves this problem it feels more natural to me to call for example ...
And imho that depends on what it is that you are actually trying to achieve, since you seem to have dismissed all other suggestion that were made in this thread.
In basics (without looking any further) you seem to wish to inherit from another class and add new properties, something that btw can also be achieved by using a helper class. (but i realize that is not what you meant).
So then it's starting to look more as if you expect templates to be a full blown form of macro's that are resolved at compile time and which are solved recursively.
In that case, i suspect that you are trying to do too many things at once and try to wrap things up in a simple one/two-liner, but which would perhaps better be solved by using several small in between steps to achieve the desired result.
But again, that entirely depends on what it is that you are actually trying to achieve. The simple examples that you have shown so far are not going to answer that.
afaik not many (compiler) developers are paying close attention to these forums, so therefor you might perhaps have more luck on posting your question on the mailing list (if you haven't done so already). That could perhaps also result in better suited answers (at least better than the ones that i am able to produce).