Generics ohne Typangabe - Ist das neu?

[Sir Rufo]

^^^^^ XE7!!!

Da habe ich doch gerade ein wenig mit Generics herumgebastelt und bin (positiv) überrascht, dass es funktioniert:

Delphi-Quellcode:

type
  TFoo = class
  public
    class procedure Bar<T>(const Value : T );
  end;

procedure Test;
var
  LBar : TBar;
begin
  TFoo.Bar( LBar ); // dieser Aufruf ist äquivalent zu
  TFoo.Bar<TBar>( LBar );
end;

Das war doch nicht immer so, oder doch? :gruebel:

[himitsu]

Kann mich nicht erinnern, daß es ging,
aber ich glaub gehört zu haben, daß dieses Verhalten wurde mehrfach gewünscht wurde.

[edit] XE geht

und http://www.delphipraxis.net/issue-433/ :stupid:

[Der schöne Günther]

Ohne eine kompetente Antwort geben zu können (spätestens Stevie wird das tun), meine ich dass es in trivialen Fällen (wie diesem) schon vor XE7 ging.

[Neutral General]

Habs grad ausprobiert. Funktioniert seit Delphi 2009 ;)
Aber hatte ich auch nicht gewusst :)

[himitsu]

getestet ... Antwort korrigiert

[Sir Rufo]

Gefühlt hatte ich eigentlich auch diese Meinung im Kopf "Woanders geht es, nur bei Delphi nicht, wollen wir auch haben!".

Na gut, wir haben (hatten schon seit Ewigkeiten) es ... dann kann man ja auch was draus machen :)

[himitsu]

Das ging nicht, glaub ich.

Delphi-Quellcode:

type
  TFoo = class
  public
    class procedure Bar<T>() : T ;
  end;

procedure Test;
var
  LBar : TBar;
begin
  LBar := TFoo.Bar; // dieser Aufruf ist äquivalent zu
  LBar := TFoo.Bar<TBar>;
end;

[Neutral General]

Jo das geht tatsächlich nicht. Auch nicht in XE7.

[Sir Rufo]

Das auch nicht

Delphi-Quellcode:

TFoo = class
  class procedure Bar<T>( AList : TList<T> );
end;

[Dejan Vu]

In C# kann man die explizite Typangabe weglassen, wenn sie sich aus dem Aufrufkontext ergibt: Hier ist der Typ des Parameters bzw. des Rückgabewertes ausreichend und definiert damit den Typparameter. Offensichtlich ist das in Delphi nicht anders.

Bei C# habe ich das erst mit dem Einsatz des Refactoringtools "Resharper" bemerkt, der gnadenlos redundanten Code moniert (wenn man ihn lässt).

[Elvis]

Zitat:

Zitat von Dejan Vu (Beitrag 1281137)

Bei C# habe ich das erst mit dem Einsatz des Refactoringtools "Resharper" bemerkt, der gnadenlos redundanten Code moniert (wenn man ihn lässt).

Ohne Generic inference könnte man fast nirgends LINQ nutzen, alleine die anonymen Typen wären ein no-go.

[Stevie]

Das Verhalten nennt sich Type inference.

Allerdings schmunzelt aufgrund der Eingeschränktheit des Delphi Compilers da jeder C# Entwickler nur drüber.

Außerdem gibt/gab es auch Stellen, wo dann was grandios falsches rauskommt (in XE z.B. konnten Floats nicht korrekt infered werden, da kam dann Kraut und Rüben bei raus). Und auch innerhalb von generischen Klassen/Methoden kann es schonmal vorkommen, dass man eigentlich <T> weglassen könnte, der Compiler aber irgendwas moniert.

Allerdings kann aufgrund der nicht vorhandenen Informationen des Compilers, dass es sich um einen konstruierten generischen Typen handelt, nur direkt auf den Typen eines Ausdrucks infered werden. Was heißt das?

Dass sowas leider nicht geht:

Delphi-Quellcode:

procedure TBar.DoIt<T>(list: TList<T>);
...

var
  fooList: TList<TFoo>;
begin
  bar.DoIt(fooList); // geht nicht

Der Compiler weiß hier nicht mehr bei fooList, aha, das ist eine TList<T>, die passt in den Parameter list und T ist TFoo, also kannste hier bei DoIt das <TFoo> weglassen.

Von Type Inference in C# bei Lambdas und generischen extension methods fang ich erstmal gar nicht an - sonst werd ich wieder depri :mrgreen:

[uligerhardt]

Zitat:

Zitat von himitsu (Beitrag 1281133)

Das ging nicht, glaub ich.

Delphi-Quellcode:

type
  TFoo = class
  public
    class procedure Bar<T>() : T ;
  end;

procedure Test;
var
  LBar : TBar;
begin
  LBar := TFoo.Bar; // dieser Aufruf ist äquivalent zu
  LBar := TFoo.Bar<TBar>;
end;

Erscheint mir auch logisch - anhand der Rückgabetypen überladen geht ja genausowenig.

[himitsu]

Zitat:

Zitat von uligerhardt (Beitrag 1281815)

anhand der Rückgabetypen überladen geht ja genausowenig.

Aber warum nicht? :cry:

Immerhin weiß der Compiler ja schon vorher was für ein Typ für den Result benötigt wird.

[Dejan Vu]

-quatsch-

[implementation]

[OT]

Zitat:

Zitat von Stevie (Beitrag 1281213)

Allerdings schmunzelt aufgrund der Eingeschränktheit des Delphi Compilers da jeder C# Entwickler nur drüber.

Und Haskeller erst. Im Vergleich dazu ist auch die Inference in C# noch billig :mrgreen:

[Stevie]

Zitat:

Zitat von uligerhardt (Beitrag 1281815)

Erscheint mir auch logisch - anhand der Rückgabetypen überladen geht ja genausowenig.

Das nennt sich return type inference und ist keineswegs unlogisch. Kann aber durchaus komplex werden, wie Eric Lippert hier und hier erklärt.

Zitat:

Zitat von implementation (Beitrag 1281820)

Und Haskeller erst. Im Vergleich dazu ist auch die Inference in C# noch billig :mrgreen:

Schon, aber eine funktionale mit einer objektorientierten Programmiersprache zu vergleichen hinkt schon ein bisschen :)

[uligerhardt]

Zitat:

Zitat von Stevie (Beitrag 1281846)

Zitat:

Zitat von uligerhardt (Beitrag 1281815)

Erscheint mir auch logisch - anhand der Rückgabetypen überladen geht ja genausowenig.

Das nennt sich return type inference und ist keineswegs unlogisch.

Hab ja auch nicht gemeint, das das Konzept Quatsch wäre, sondern, dass mir logisch erscheint, dass es in Delphi nicht für Generics implementiert ist, wenn's nichtmal für overload funktioniert.

[himitsu]

Overload kann es so grundsätzlich erstmal beim Result nicht gehen .... nicht ohne soein Inferenzzeugs, denn abgesehn von expliziten Casts könnte der Compiler sonst keine Entscheidung treffen was er nun nehmen solle.

Delphi nutzt (aktuell) halt ausschließlich die Eingabeparameter, für diese Entscheidungen, und eben nicht den Ausgabeparameter Result.
Aber wenn man es genau nimmt, dann ist auch das Result ein "Parameter", welcher intern oftmals sogar als VAR-Parameter übergeben wird.

[Dejan Vu]

Ja, aber deswegen musst Du auch bei nicht passenden oder zu allgemeinen Parametern den Typen mit angeben. Ein Overload mit jeweils einem Objektparameter geht ja auch u.U. nach hinten los.

Delphi-Quellcode:

Procedure Foo (bar : TFooBar); overload;
Procedure Foo (bar : TBarFoo); overload;
...
Foo (nil); // <<--- möööp