Am 20.11.2022 um 02:02 schrieb Hairy Pixels:
On Nov 20, 2022, at 4:26 AM, Sven Barth via fpc-pascal
<fpc-pascal@lists.freepascal.org> wrote:
// this kind of constraint that uses T does not work yet
generic TList<T; Comparer: specialize TComparer<T>> = class
procedure Sort;
end;
Does this mean the generic param “Comparer” has a constraint which is "specialize
TComparer<T>”? I’ve not ever considered this before but I think it solvers the
problem where I suggested you could use something like traits.
Yes, those are type constraints. As long as you don't use types that
were introduced in the same parameter list then it already works. E.g.:
=== code begin ===
program Project1;
{$mode objfpc}{$H+}
type
generic TGen<T> = class
end;
generic TTest<T: specialize TGen<LongInt>> = class
end;
TGenLongInt = specialize TGen<LongInt>;
TTestLongInt = specialize TTest<TGenLongInt>;
begin
end.
=== code end ===
Though I wouldn't really compare that with traits.
What is the challenge involved in implemented that so that it hasn’t been
done yet? Just curious. :)
Mainly that a temporary symtable needs to be inserted before starting to
parse the generic parameter types that is then passed along in the
parser until the parameters are added to the final symbol table of the
type or routine where the generic parameters reside.
And related since it comes to mind now, what is the reason generics inside of
generics (like a generic method inside a generic class) are not supported and
what challenges are involved?
The main problem is that the recording of the tokens and the use of the
recorded tokens are managed correctly. E.g. should a generic method
inside a generic class have it's tokens recorded when they're already
recorded as part of the type and will be recorded again as a separate
method when the class is specialized?
Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
