Generics ohne Typangabe - Ist das neu?

[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