Typ-Kompatibilitäts-Regeln bei Generics mit overloads

[DenkDirNix]

Dieses Verhalten (Aufruf {2} im Code) hat mich (nach etlichen Programmier-Stunden in der Annahme dass es anders wäre) kalt überrascht:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

type
  TMyclass = class
    class procedure Send   ( v: word ); overload;
    class procedure Send<T>( v: T    ); overload;
  end;

var
  b: byte = 255;
  w: word = 256;


class procedure TMyclass.Send( v: word );
begin
  writeln( 'Send' );
end;

class procedure TMyclass.Send<T>( v: T );
begin
  writeln( 'Send<T>' );
end;


begin
{1} TMyclass.Send<byte>( b );    //  ruft Send<T> auf, okay
{2} TMyclass.Send      ( b );    //  ruft Send<T> auf,  ??
{3} TMyclass.Send<word>( w );    //  ruft Send<T> auf  naja
{4} TMyclass.Send      ( w );    //  ruft Send    auf, okay
ReadLn
end.

Die Typ-Kompatibilität der generischen Methode Send<T> wird bei der Auswahl der passenden overload-Methode für Aufruf {2} als stärker gewichtet als die Kompatibilität des Aufruf-Parameter-Typs "byte" zum formalen Parameter-Typ "word" des nicht-generischen Send.
Zumindest das Fehlen des konkreten Typs <byte> sollte doch den Compiler dazu bewegen, nur die nicht-generischen overloads in Betracht zu ziehen. Hätte ich so gedacht...

[Der schöne Günther]

Klar ist das bestimmt nirgendwo formalisiert, aber ich finde das wenig überraschend: Angenommen es wären

Delphi-Quellcode:

var

oder

Delphi-Quellcode:

const

-Parameter: Da kann er ja schlecht das

Delphi-Quellcode:

Byte

in die Methode mit dem

Delphi-Quellcode:

Word

-Parameter stecken, nur weil ein Byte auch in ein Word "passen" würde.

[himitsu]

Zitat:

naja

Bei 3 und auch 1 sagst du explizit, dass <T> genommen werden soll/muss.

Bei 4 passt der Typ ganz genau, auf dessen Signatur.

Und bei 2 ......... Type Inference (implizite Wahl des T, anhand des Typs vom Parameter)
https://www.developer-experts.net/20...neric-methods/

[Redeemer]

Zitat:

Zitat von Der schöne Günther (Beitrag 1544108)

Angenommen es wären

Delphi-Quellcode:

var

oder

Delphi-Quellcode:

const

-Parameter: Da kann er ja schlecht das

Delphi-Quellcode:

Byte

in die Methode mit dem

Delphi-Quellcode:

Word

-Parameter stecken, nur weil ein Byte auch in ein Word "passen" würde.

Bei const kann ich das sehr wohl.

[himitsu]

Bei

Delphi-Quellcode:

var

und

Delphi-Quellcode:

out

und vermutlich auch

Delphi-Quellcode:

const [ref]

muß es genau passen und es muß eine Variable sein.

Bei nichts und

Delphi-Quellcode:

const

entscheidet Delphi, ob als Referenz oder Value und ob es auch eine Kopie
und es kann auch eine Kopie sein, was z.B. für Function-Result und Property nötig wäre.

[Stevie]

Wenn es keine exakte Übereinstimmung mit einer nicht generischen Überladung gibt, hat immer die generische Methode Vorrang gegenüber einer Überladung, für die eine sogenannte "widening conversion" ausgeführt werden muss.

Das ist mal ausnahmsweise auch genauso wie in einer gewissen anderen Programmiersprache.

[DenkDirNix]

Zitat:

Zitat von Stevie (Beitrag 1544114)

Wenn es keine exakte Übereinstimmung mit einer nicht generischen Überladung gibt, hat immer die generische Methode Vorrang gegenüber einer Überladung, für die eine sogenannte "widening conversion" ausgeführt werden muss.

Sehr schön knackig und präzise formuliert.:thumb:

Ich war halt auf die Annahme hereingefallen, dass zur Auflösung von Aufrufen ohne Typangabe <...> nur nicht-generische overload-Varianten in Betracht kommen.