Constants in generics

classic Classic list List threaded Threaded
96 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

Free Pascal - General mailing list
Am Mi., 28. Nov. 2018, 09:41 hat Ryan Joseph <[hidden email]> geschrieben:
I just noticed I sent this to the wrong person and the list never saw it so I’m sending it again. I feel like I should try to fix it while I’ve got my eyes on the generics code before I forget.

Is there a reason it’s not implemented yet? In theory you should be able to specialize a function as a type and use the type name as the function name. This is basically the same syntax for class construction but without the .create.

====================

As a side node I haven’t been willing to use generic functions yet because the syntax is so verbose it kind of defeats the purpose.

Why can’t we specialize functions as a type? Maybe that’s on the todo list also?

Because that is not supposed to work. Generic routines are *routines*, not types. You can't define aliases for routines either, not to mention the problems with scoping as generic methods exist as well. 

Generic routines however have a different boon in Delphi that I plan to add as well: inference of the type parameters based on the parameters the user passed. In that case the type parameter clause as well as the "specialize" in non-Delphi modes would not need to be used and it would look like a normal, non-generic call. 

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

Ryan Joseph


> On Nov 28, 2018, at 7:26 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> Because that is not supposed to work. Generic routines are *routines*, not types. You can't define aliases for routines either, not to mention the problems with scoping as generic methods exist as well.

It seems natural you could specialize a generic procedure because you can do this for all other generic types. Maybe a type isn’t the right way but it feels like there should be some way to specialize the procedure header outside of a begin/end block. I know you can't make aliases to procedures but generics are more of “instantiating a template” which falls outside the scope the language in general.

>
> Generic routines however have a different boon in Delphi that I plan to add as well: inference of the type parameters based on the parameters the user passed. In that case the type parameter clause as well as the "specialize" in non-Delphi modes would not need to be used and it would look like a normal, non-generic call.

That’s probably the best way (Swift does this and I always wondered why FPC doesn’t) but it won’t work unless the parameters contain the generic parameter, which is a minority of generics functions anyways.
 
Just to be sure, you mean like this?

generic procedure DoThis<T>(msg:T);
begin
end;

begin
       
        DoThis(‘hello’); // compiles as “specialize DoThis<string>(‘hello’)” because param types match generic parameter types

If all that’s involved is comparing params types to generic types then that looks like a relatively simple solution.  Const generic params may have complicated this some however.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

Free Pascal - General mailing list
Am Mi., 28. Nov. 2018, 15:27 hat Ryan Joseph <[hidden email]> geschrieben:


> On Nov 28, 2018, at 7:26 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> Because that is not supposed to work. Generic routines are *routines*, not types. You can't define aliases for routines either, not to mention the problems with scoping as generic methods exist as well.

It seems natural you could specialize a generic procedure because you can do this for all other generic types. Maybe a type isn’t the right way but it feels like there should be some way to specialize the procedure header outside of a begin/end block. I know you can't make aliases to procedures but generics are more of “instantiating a template” which falls outside the scope the language in general.

You're not wrong, but a type alias is definitely the wrong way. 
But that is a completely different topic, one that I'm not willing to discuss right now, aside from "we don't support something like that".


>
> Generic routines however have a different boon in Delphi that I plan to add as well: inference of the type parameters based on the parameters the user passed. In that case the type parameter clause as well as the "specialize" in non-Delphi modes would not need to be used and it would look like a normal, non-generic call.

That’s probably the best way (Swift does this and I always wondered why FPC doesn’t) but it won’t work unless the parameters contain the generic parameter, which is a minority of generics functions anyways.

Just to be sure, you mean like this?

generic procedure DoThis<T>(msg:T);
begin
end;

begin

        DoThis(‘hello’); // compiles as “specialize DoThis<string>(‘hello’)” because param types match generic parameter types

If all that’s involved is comparing params types to generic types then that looks like a relatively simple solution.  Const generic params may have complicated this some however.

Yes, all generic parameters need to be part of the routine's parameters and constant parameters indeed won't work in that case. 

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

Free Pascal - General mailing list
In reply to this post by Free Pascal - General mailing list
Am 27.11.2018 um 11:35 schrieb Sven Barth:
Am Di., 27. Nov. 2018, 08:18 hat Ryan Joseph <[hidden email]> geschrieben:


> On Nov 27, 2018, at 4:59 AM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> Best check again once you've done the switch to tconstsym for constants. :)
>

I made most of the changes you mentioned so please look. Including the constsyms didn’t break anything and helped to clean up the code. I would have done that from the start but I wasn’t sure you wanted me mixing in new types.

Good, thank you. Hopefully I'll find the time this evening to look at your changes again. :)

Looks better.
The next thing to nuke is the tgenericparamdef. The parameters stored in tdef.genericparas are the parameter symbols, so there should be no need for defs. If necessary some of the code in pgenutil (and related functions) will need to be changed from handling a list of defs to a list of syms.

Regards,
Sven

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

Ryan Joseph


> On Nov 29, 2018, at 5:15 AM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> Looks better.
> The next thing to nuke is the tgenericparamdef. The parameters stored in tdef.genericparas are the parameter symbols, so there should be no need for defs. If necessary some of the code in pgenutil (and related functions) will need to be changed from handling a list of defs to a list of syms.

I added that extra type so that it would be compatible with genericdeflist. I don’t see how that can be removed. The const sym is pulled out in generate_specialization_phase2 and renamed (which I forget why already).

So the tgenericparamdef is just a vessel to hold the constsym until generate_specialization_phase2? Either way removing it means breaking genericdeflist right?

if typeparam.nodetype <> typen then
  begin
    { the typesym from paramdef will be added to the list in generate_specialization_phase2 }
    paramdef := tgenericparamdef.create(typeparam.resultdef,typeparam,constprettyname);
    genericdeflist.Add(paramdef);
  end
else
  begin
    constprettyname := '';
    genericdeflist.Add(typeparam.resultdef);
  end;

from generate_specialization_phase2:

for i:=0 to genericdef.genericparas.Count-1 do
  begin
    srsym:=tsym(genericdef.genericparas[i]);
    if not (sp_generic_para in srsym.symoptions) then
      internalerror(2013092602);

    // note: ryan
    { set the generic param name of the constsym of tgenericparamdef }
    typedef := tstoreddef(context.genericdeflist[i]);
    if typedef.typ = genericconstdef then
      tgenericparamdef(typedef).typesym.realname := srsym.realname;
   
    generictypelist.add(srsym.realname,typedef.typesym);
  end;

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

Ryan Joseph
In reply to this post by Free Pascal - General mailing list


> On Nov 28, 2018, at 11:25 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> You're not wrong, but a type alias is definitely the wrong way.
> But that is a completely different topic, one that I'm not willing to discuss right now, aside from "we don't support something like that”.

Ok, maybe something to think about later. Compile time performance could be a reason to pursue down the road.

> If all that’s involved is comparing params types to generic types then that looks like a relatively simple solution.  Const generic params may have complicated this some however.
>
> Yes, all generic parameters need to be part of the routine's parameters and constant parameters indeed won't work in that case.

What are the performance implications of specializing all these types across a code base? I’ve heard c++ developers mention the terrible performance of templates and I think that’s because of the inferred types and inability to specialize once (like FPC does for all other generics except procs).

Looking at this now I think that each unit that uses an inferred specialization will produce a unit procedure for just that unit. Is that right?

Here’s an example which specializes 3 generics (they’re shared right?) across 5 procedure calls.

generic procedure DoThis<T>(msg:T);
begin
end;

generic procedure DoThis<T>(msg:T;param1:T);
begin
end;

generic procedure DoThis<T>(msg:T;param1:integer);
begin
end;

begin
        DoThis('hello'); // specialize DoThis<string>('hello');
        DoThis(1); // specialize DoThis<integer>(1);
        DoThis('a','b'); // specialize DoThis<string>('a','b’);
        DoThis(1,1); // specialize DoThis<integer>(1,1);
        DoThis('hello',1); // specialize DoThis<string>(‘hello',1);

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

denisgolovan
In reply to this post by Ryan Joseph
Hi, all

Could someone confirm this functionality is merged into trunk? I mean constants in generics.


29.11.2018, 05:24, "Ryan Joseph" <[hidden email]>:



 On Nov 29, 2018, at 5:15 AM, Sven Barth via fpc-pascal <fpc-pascal@...> wrote:

 Looks better.
 The next thing to nuke is the tgenericparamdef. The parameters stored in tdef.genericparas are the parameter symbols, so there should be no need for defs. If necessary some of the code in pgenutil (and related functions) will need to be changed from handling a list of defs to a list of syms.


I added that extra type so that it would be compatible with genericdeflist. I don’t see how that can be removed. The const sym is pulled out in generate_specialization_phase2 and renamed (which I forget why already).

So the tgenericparamdef is just a vessel to hold the constsym until generate_specialization_phase2? Either way removing it means breaking genericdeflist right?

if typeparam.nodetype <> typen then
  begin
    { the typesym from paramdef will be added to the list in generate_specialization_phase2 }
    paramdef := tgenericparamdef.create(typeparam.resultdef,typeparam,constprettyname);
    genericdeflist.Add(paramdef);
  end
else
  begin
    constprettyname := '';
    genericdeflist.Add(typeparam.resultdef);
  end;

from generate_specialization_phase2:

for i:=0 to genericdef.genericparas.Count-1 do
  begin
    srsym:=tsym(genericdef.genericparas[i]);
    if not (sp_generic_para in srsym.symoptions) then
      internalerror(2013092602);

    // note: ryan
    { set the generic param name of the constsym of tgenericparamdef }
    typedef := tstoreddef(context.genericdeflist[i]);
    if typedef.typ = genericconstdef then
      tgenericparamdef(typedef).typesym.realname := srsym.realname;

    generictypelist.add(srsym.realname,typedef.typesym);
  end;

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist - fpc-pascal@...
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pas…



--
Regards,
Denis Golovan


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

Free Pascal - General mailing list
Am Mi., 2. Jan. 2019, 11:20 hat denisgolovan <[hidden email]> geschrieben:
Hi, all

Could someone confirm this functionality is merged into trunk? I mean constants in generics.

I can confirm that it is not integrated in trunk. 

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

denisgolovan

Well, I'll wait then.
That's definitely nice to have feature.


02.01.2019, 16:33, "Sven Barth via fpc-pascal" <[hidden email]>:
Am Mi., 2. Jan. 2019, 11:20 hat denisgolovan <denisgolovan@...> geschrieben:
Hi, all

Could someone confirm this functionality is merged into trunk? I mean constants in generics.

I can confirm that it is not integrated in trunk. 

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist - fpc-pascal@...
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pas…



--
Regards,
Denis Golovan


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

Free Pascal - General mailing list
In reply to this post by Ryan Joseph
06.11.2018 10:13, Ryan Joseph пишет:
>
> program generic_constants;
>
> type
> generic TList<T, U> = record
> list: array[0..U-1] of T;
> function capacity: integer;
> end;
>

I`d like to see constant parameter to be constrained with type

  type
        generic TList<T; U: Integer> = record
  list: array[0..U-1] of T;
  function capacity: integer;
  end;

--
AVS
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

Free Pascal - General mailing list
Am Mi., 2. Jan. 2019, 23:41 hat Alexander Shishkin via fpc-pascal <[hidden email]> geschrieben:
06.11.2018 10:13, Ryan Joseph пишет:
>
> program generic_constants;
>
> type
>       generic TList<T, U> = record
>               list: array[0..U-1] of T;
>               function capacity: integer;
>       end;
>

I`d like to see constant parameter to be constrained with type

  type
        generic TList<T; U: Integer> = record
                list: array[0..U-1] of T;
                function capacity: integer;
        end;

That's already been taken care of by Ryan :) 

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

Free Pascal - General mailing list
Thanks, now I`ve lost is a discussion again. What is the decision about
syntax? Is "const" prefix and/or ": type" suffix required?


generic TList1<T, U> = class
   var data: array[0..U] of T; end;

generic TList2<T; U: Integer> = class
   var data: array[0..U] of T; end;

generic TLis3<T; const U> = class
   var data: array[0..U] of T; end;

generic TList4<T; const U: integer> = class
   var data: array[0..U] of T; end;



03.01.2019 2:15, Sven Barth via fpc-pascal пишет:

> Am Mi., 2. Jan. 2019, 23:41 hat Alexander Shishkin via fpc-pascal
> <[hidden email]
> <mailto:[hidden email]>> geschrieben:
>
>     06.11.2018 10:13, Ryan Joseph пишет:
>      >
>      > program generic_constants;
>      >
>      > type
>      >       generic TList<T, U> = record
>      >               list: array[0..U-1] of T;
>      >               function capacity: integer;
>      >       end;
>      >
>
>     I`d like to see constant parameter to be constrained with type
>
>        type
>              generic TList<T; U: Integer> = record
>                      list: array[0..U-1] of T;
>                      function capacity: integer;
>              end;
>
>
> That's already been taken care of by Ryan :)
>
> Regards,
> Sven
>
--AVS

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

Ryan Joseph
In reply to this post by Free Pascal - General mailing list


> On Jan 2, 2019, at 3:13 PM, Alexander Shishkin via fpc-pascal <[hidden email]> wrote:
>
> I`d like to see constant parameter to be constrained with type
>
> type
> generic TList<T; U: Integer> = record
> list: array[0..U-1] of T;
> function capacity: integer;
> end;

This is the syntax we’ve settled on.

type
        generic TList<T, const U: integer> = record
                list: array[0..U-1] of T;
                function capacity: integer;
        end;

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

Ryan Joseph
In reply to this post by Free Pascal - General mailing list


> On Jan 2, 2019, at 5:52 PM, Alexander Shishkin via fpc-pascal <[hidden email]> wrote:
>
> Thanks, now I`ve lost is a discussion again. What is the decision about syntax? Is "const" prefix and/or ": type" suffix required?

const is required but the type is not.

Here’s a test for all the const types supported.

program gc_types;
uses
        sysutils;

type
        generic TMyRecord_Int<T, const U:integer> = record
        end;

type
        generic TMyRecord_Byte<T, const U:byte> = record
        end;

type
        generic TMyRecord_String<T, const U:string> = record
        end;

type
        generic TMyRecord_Float<T, const U:single> = record
        end;

type
        TDay = (Mon, Tue, Wed);
        TDays = set of TDay;
        generic TMyRecord_Set<T, const U:TDays> = record
        end;

type
        generic TMyRecord_Nil<T, const U:pointer> = record
        end;


type
        generic TMyRecord_Undefined<T, const U> = record
        end;

var
        a: specialize TMyRecord_Int<integer,10>;
        b: specialize TMyRecord_String<integer,'foo'>;
        c: specialize TMyRecord_Float<integer,0.1>;
        d: specialize TMyRecord_Set<integer,[Mon, Wed]>;
        e: specialize TMyRecord_Nil<integer,nil>;
        f: specialize TMyRecord_Byte<integer,kByte>;
        g: specialize TMyRecord_Undefined<integer,[1,2,3]>;
begin
end.


Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

Free Pascal - General mailing list
03.01.2019 4:29, Ryan Joseph пишет:
>
> type
> generic TMyRecord_Int<T, const U:integer> = record
> end;
>

This is not consistent with constraints. Should be ";" after T.

And what about following examples?

type
  generic TMyRecord1<const T, const U> = record
  end;

type
  generic TMyRecord2<const T; const U> = record
  end;

type
  generic TMyRecord3<const T, U> = record
  end;

type
  generic TMyRecord4<const T; U> = record
  end;
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

Ryan Joseph


> On Jan 2, 2019, at 8:25 PM, Alexander Shishkin via fpc-pascal <[hidden email]> wrote:
>
> This is not consistent with constraints. Should be ";" after T.
>
> And what about following examples?
>

The semicolon is only needed following a generic parameter which is constrained. This was the normal behavior before constants were introduced.

generic TMyRecord1<T: TObject; const U: integer> = record


Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

Free Pascal - General mailing list
03.01.2019 6:32, Ryan Joseph пишет:

>
>
>> On Jan 2, 2019, at 8:25 PM, Alexander Shishkin via fpc-pascal <[hidden email]> wrote:
>>
>> This is not consistent with constraints. Should be ";" after T.
>>
>> And what about following examples?
>>
>
> The semicolon is only needed following a generic parameter which is constrained. This was the normal behavior before constants were introduced.
>
> generic TMyRecord1<T: TObject; const U: integer> = record
>

It is not exactly true, semicolon separates parameter lists different
restrictions including empty one.

This should fail to compile (": integer" restriction can not be applied
to non const parameter):
generic TMyRecord1<T, const U: integer> = record end;
generic TMyRecord1<const T, U: integer> = record end;

This is OK (T is any type):
generic TMyRecord1<T; const U: integer> = record end;

This is OK (both T and U are integer):
generic TMyRecord1<const T, const U: integer> = record end;

This is OK (T is any const,  U and V are integer)
generic TMyRecord1<const T; const U, const V: integer> = record end;

--AVS

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

Free Pascal - General mailing list
On Thu, 3 Jan 2019 14:58:00 +0300
Alexander Shishkin via fpc-pascal <[hidden email]>
wrote:

>[...]
> This is OK (both T and U are integer):
> generic TMyRecord1<const T, const U: integer> = record end;

That is inconsistent to normal Pascal arguments.

<accessors> Name[, Name ...][:type]

Isn't it?

Mattias
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

Free Pascal - General mailing list
In reply to this post by Free Pascal - General mailing list
Am Do., 3. Jan. 2019, 12:58 hat Alexander Shishkin via fpc-pascal <[hidden email]> geschrieben:
03.01.2019 6:32, Ryan Joseph пишет:
>
>
>> On Jan 2, 2019, at 8:25 PM, Alexander Shishkin via fpc-pascal <[hidden email]> wrote:
>>
>> This is not consistent with constraints. Should be ";" after T.
>>
>> And what about following examples?
>>
>
> The semicolon is only needed following a generic parameter which is constrained. This was the normal behavior before constants were introduced.
>
> generic TMyRecord1<T: TObject; const U: integer> = record
>

It is not exactly true, semicolon separates parameter lists different
restrictions including empty one.

This should fail to compile (": integer" restriction can not be applied
to non const parameter):
generic TMyRecord1<T, const U: integer> = record end;
generic TMyRecord1<const T, U: integer> = record end;

This is OK (T is any type):
generic TMyRecord1<T; const U: integer> = record end;

This is OK (both T and U are integer):
generic TMyRecord1<const T, const U: integer> = record end;

This is OK (T is any const,  U and V are integer)
generic TMyRecord1<const T; const U, const V: integer> = record end;

Correct. ";" separates different parameter types, "," separates those of the same type. Though I agree with Mattias that "const T, const U" (with or without ": Integer") should not work (but then "T, const U" should also not work for consistency). 
Essentially it should behave like a routine's parameter clause. 

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Constants in generics

Free Pascal - General mailing list
In reply to this post by Free Pascal - General mailing list
03.01.2019 15:45, Mattias Gaertner via fpc-pascal пишет:

> On Thu, 3 Jan 2019 14:58:00 +0300
> Alexander Shishkin via fpc-pascal <[hidden email]>
> wrote:
>
>> [...]
>> This is OK (both T and U are integer):
>> generic TMyRecord1<const T, const U: integer> = record end;
>
> That is inconsistent to normal Pascal arguments.
>
> <accessors> Name[, Name ...][:type]
>
> Isn't it?
>

I personally do not like const prefix either. More consistent with other
constraints would be:

T and U integer const
generic TMyRecord1<T, U: integer> = record end;
generic TMyRecord1<T, U: const, integer> = record end;

Similar to
generic TMyRecord1<T, U: IUnknown> = record end;
generic TMyRecord1<T, U: class, IUnknown> = record end;

T and U any const
generic TMyRecord1<T, U: const> = record end;

Similar to
generic TMyRecord1<T, U: record> = record end;

And more complex example:

generic TMyRecord1<T, U: record; X, Y: const> = record end;
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12345