View Issue Details

IDProjectCategoryView StatusLast Update
0026181FPCCompilerpublic2015-01-06 14:42
ReporterMaciej Izak Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version2.7.1 
Summary0026181: Can't determine which overloaded function to call for generic version of code
DescriptionFor non-generic code all works fine, but generic version raise error:
b004.lpr(8,30) Error: Can't determine which overloaded function to call.

Non generic version attached as: nongeneric.zip (nong004.lpr and nong004u01.pas)
Generic version attached as: generic.zip (b004.lpr and b004u01.pas)
======b004u01.pas======
unit b004u01;
{$mode delphi}
interface

type
  IA<T> = interface
  end;

  IB<T> = interface
  end;

  TA<T> = class(TInterfacedObject, IA<T>, IB<T>)
  end;

  TB<T> = class
  protected
    constructor Create(A: IA<T>); virtual; abstract; overload;
  public
    constructor Create(B: IB<T>); virtual; abstract; overload;
  end;

  TC<T> = class
    class var F: TA<T>;
  end;
implementation
end.

======b004.lpr======
program b004;
{$MODE DELPHI}
uses b004u01;
begin
  TB<Byte>.Create(TC<Byte>.F);
end.
Tagsgenerics
Fixed in Revision
FPCOldBugId
FPCTarget
Attached Files

Relationships

related to 0027206 resolvedSven Barth [Patch] Christmas gift by FreeSparta : Generics.Collections 

Activities

Maciej Izak

2014-05-17 19:05

reporter  

generic.zip (595 bytes)

Maciej Izak

2014-05-17 19:05

reporter  

nongeneric.zip (595 bytes)

Thaddy de Koning

2014-05-18 13:34

reporter   ~0075068

Last edited: 2014-05-18 13:36

View 2 revisions

Hm.
Again, this is correct. F can be anything (any combination you declared+anything else and for both interfaces) at that point.

I wonder if you understand generics. They are not a fix for all.

Programming is not DWIM proof yet ;)

Thaddy de Koning

2014-05-18 13:43

reporter   ~0075069

Last edited: 2014-05-18 14:05

View 6 revisions

Even if it were philosophically correct (which it isn't!: it is mathematically unsolvable) you would run into practical problems evaluating this because of the possible depth of combinations and possibly even endless recursion solving every F for T.

It needs to be solved because both interfaces can be invoked with unknown but different T's and even the class can be invoked with a third T and the T's can be changed left to right to complicate matters further.

The error message is correct.

If you mean the same T for all of your code, consider f.e. to use inner classes and pass JUST T in the constructor of the main class so it is clear you mean just one type of T.

Thaddy de Koning

2014-05-18 13:54

reporter   ~0075071

The paradox is that T = T, while also being T <> T.
That makes my day, btw. I like it ;)

Maciej Izak

2014-05-18 15:57

reporter   ~0075088

Last edited: 2014-05-18 16:03

View 2 revisions

Please close the report as "won't fix" :), this is probably not a bug (It depends how is interpreted the visibility of generic classes, specialized in Delphi way in other modules for protected sections). The solution is a strict protected section instead of protected.

Thaddy de Koning

2014-05-19 19:07

reporter   ~0075116

That was what I also could have hinted at.. ;-)
The other case is just a misunderstanding. You can't assert T with a defined type.
Was fun though.

Maciej Izak

2014-05-19 21:25

reporter   ~0075120

@Thaddy: "I wonder if you understand generics. They are not a fix for all."

>.<... This bug report is a simplified code from Generics.*, and one of the basic and important generics construction (some variant of singleton pattern - for more details go to Generics.Defaults in Delphi RTL, at this moment my more advanced FPC Generics.Deafults version is on the way).

Sven Barth

2014-06-03 09:39

manager   ~0075429

@Thaddy: F can not be anything. In the main method F is a TA<Byte> and thus a completely defined type.

The problem is the way generics work: When using TB<Byte> the generic TB<T> is reparsed inside the b004 file as is TC<T> for TC<Byte>. This means TB<Byte> and TC<Byte> (and by extension TA<Byte>) now appear both as if declared in b004 and thus the compiler sees both constructors of TA<Byte> and thus can't determine the correct one to call. That's also why using "strict protected" solved this issue for you and why there's no problem in the non generic variant.
I'll need to check how Delphi handles this (and I so hope that it handles it correctly) and then will need to adjust the visibility checks accordingly...

Regards,
Sven

Sven Barth

2014-06-14 21:54

manager   ~0075691

Last edited: 2014-06-14 21:54

View 2 revisions

At least Delphi XE doesn't compile it either... *sigh*

Edit: and it strongly dislikes the abstract constructors.

Regards,
Sven

Maciej Izak

2014-06-14 23:01

reporter   ~0075693

I have mixed feelings about this report >.< ... On the one hand it is good to have access (unexpected access) to protected section in such a way but on the other hand, I feel that is bad...

Issue History

Date Modified Username Field Change
2014-05-17 19:05 Maciej Izak New Issue
2014-05-17 19:05 Maciej Izak File Added: generic.zip
2014-05-17 19:05 Maciej Izak File Added: nongeneric.zip
2014-05-18 13:34 Thaddy de Koning Note Added: 0075068
2014-05-18 13:36 Thaddy de Koning Note Edited: 0075068 View Revisions
2014-05-18 13:43 Thaddy de Koning Note Added: 0075069
2014-05-18 13:44 Thaddy de Koning Note Edited: 0075069 View Revisions
2014-05-18 13:47 Thaddy de Koning Note Edited: 0075069 View Revisions
2014-05-18 13:49 Thaddy de Koning Note Edited: 0075069 View Revisions
2014-05-18 13:51 Thaddy de Koning Note Edited: 0075069 View Revisions
2014-05-18 13:54 Thaddy de Koning Note Added: 0075071
2014-05-18 14:05 Thaddy de Koning Note Edited: 0075069 View Revisions
2014-05-18 15:57 Maciej Izak Note Added: 0075088
2014-05-18 16:03 Maciej Izak Note Edited: 0075088 View Revisions
2014-05-19 19:07 Thaddy de Koning Note Added: 0075116
2014-05-19 21:25 Maciej Izak Note Added: 0075120
2014-05-22 07:37 Maciej Izak Tag Attached: generics
2014-06-03 09:39 Sven Barth Note Added: 0075429
2014-06-14 21:54 Sven Barth Note Added: 0075691
2014-06-14 21:54 Sven Barth Note Edited: 0075691 View Revisions
2014-06-14 23:01 Maciej Izak Note Added: 0075693
2015-01-06 14:42 Sven Barth Relationship added related to 0027206