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 var oder const -Parameter: Da kann er ja schlecht das Byte in die Methode mit dem 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 von Der schöne Günther:

Angenommen es wären var oder const -Parameter: Da kann er ja schlecht das Byte in die Methode mit dem Word -Parameter stecken, nur weil ein Byte auch in ein Word "passen" würde.

Bei const kann ich das sehr wohl.

[himitsu]

Bei var und out und vermutlich auch const [ref] muß es genau passen und es muß eine Variable sein.

Bei nichts und 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 von 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.

Sehr schön knackig und präzise formuliert.

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