[fpc-devel] potential bug, generics vs helpers

[Sven Barth]

Am 27.01.2012 17:46, schrieb Thaddy:
> On 27-1-2012 17:25, Marco van de Voort wrote:
>> In our previous episode, Kornel Kisielewicz said:
>>> {$apptype console}
>>>
>>> Type
>>> TLIST<T>=class
>>> end;
>>>
>>> type
>>> Ta= TLIST<POINTER>;
>>> TB= TLIST<POINTER>;
> This may very well be a (semantics) bug in Delphi.
> Did you put this to Embarcadero?
> IMO a type Ta<..> should never be assignable to a type Tb<..> and
> reverse when using generics. (unless with operator overloading or
> similar defined)
> I think this may be an unintentional "feature" in Delphi.

I now tested a "generic diamond" in Delphi XE.

Following setup:

===

unit ugendiamonddecl;

interface

type
   TGeneric<T> = class
     f: T;
   end;

implementation

end.

===

unit ugendiamond1;

interface

uses
   ugendiamonddecl;

type
   TSpez1 = TGeneric<LongInt>;

implementation

end.

===

unit ugendiamond2;

interface

uses
   ugendiamonddecl;

type
   TSpez2 = TGeneric<LongInt>;

implementation

end.

===

program tgendiamond;

{$APPTYPE CONSOLE}

uses
//  ugendiamonddecl in 'ugendiamonddecl.pas',
   ugendiamond1 in 'ugendiamond1.pas',
   ugendiamond2 in 'ugendiamond2.pas';

var
   s1: TSpez1;
   s2: TSpez2;
begin
   s1 := s2;
end.

===

This compiles!

So there MUST be specific code in place in the Delphi compiler to allow 
the assignment from ugendiamond2.TSpez2 to ugendiamond1.TSpez1 as those 
are different definitions. Thus this can not be a bug, but must be an 
intentional feature. Allowing this in FPC as well would be doable.

Now regarding Kornel's problem: we could(!) change the way the compiler 
works in non-Delphi modes to what is described in the documentation (by 
adding the type symbol's name to the generic's name as well), but this 
will mean that we would have to define how units in Delphi and 
non-Delphi modes can interact here. After that the corresponding code in 
the compiler can be implemented to ensure this.

Regards,
Sven