Pourquoi les délégués anonymes/lambdas ne déduisent-ils pas les types de paramètres out/ref?

Question

Plusieurs questions C# sur StackOverflow vous demandent comment créer des délégués/lambdas anonymes avec les paramètres out ou ref. Voir, par exemple:

• Calling a method with ref or out parameters from an anonymous method
• Write a lambda or anonymous function that accepts an out parameter

Pour ce faire, il vous suffit de spécifier le type de paramètre, comme dans:

public void delegate D(out T p); 
// ... 
D a = (out T t) => { ... };  // Lambda syntax. 
D b = delegate(out T t) { ... }; // Anonymous delegate syntax. 

Qu'est-ce que Je suis curieux de savoir pourquoi le type est explicitement requis. Y a-t-il une raison particulière que c'est le cas? Autrement dit, du point de vue du compilateur/du langage, pourquoi les éléments suivants ne sont-ils pas autorisés?

D a = (out t) => { ... };  // Lambda syntax -- implicit typing. 
D b = delegate(out t) { ... }; // Anonymous delegate syntax -- implicit typing. 

ou mieux encore, il suffit:

D a = (t) => { ... };  // Lambda syntax -- implicit typing and ref|out-ness. 
D b = delegate(t) { ... }; // Anonymous delegate syntax -- implicit typing and ref|out-ness. 

Answer 1

question intéressante.

D'abord, considérons la différence entre les méthodes anonymes et les lambdas. Du point de vue du rédacteur du compilateur, la différence la plus importante est que lambdas peut exiger que le compilateur infère le type des paramètres de la cible à laquelle le lambda est assigné; Les méthodes anonymes C# 2 n'ont pas cette fonctionnalité. Cette fonctionnalité semble être une petite différence mais en fait, elle a des ramifications majeures sur l'implémentation du compilateur. Voir ma série de blog sur ce sujet pour quelques réflexions sur les raisons qui est:

http://blogs.msdn.com/ericlippert/archive/2007/01/10/lambda-expressions-vs-anonymous-methods-part-one.aspx

nous donc maintenant de venir à votre question réelle: pourquoi ne pas déduire extériorité/refness du type de cible aux paramètres du lambda. Autrement dit, si nous avons un délégué D (out int x) alors sûrement D d = x => {x = 10; } pourrait déduire que x est "out int".

Il n'y a pas de raison technique pour laquelle je ne sais pas pourquoi nous ne pourrions pas faire cela. En interne dans le compilateur, les types out/ref sont représentés comme des types comme les autres.

Cependant, les fonctionnalités ne sont pas réalisées uniquement parce qu'elles peuvent être réalisées; ils se font parce qu'il y a une raison impérieuse de le faire.Pour les lambdas, la raison impérieuse de faire une inférence de type en premier lieu est LINQ; nous voulons être en mesure de faire une transformation syntaxique simple sur une compréhension de requête dans un appel de méthode avec lambdas, et laisser le moteur d'inférence de type de méthode élaborer les types de tous les paramètres lambda. Aucune des méthodes LINQ générées n'a de délégué avec des paramètres out ou ref.

Donc, nous n'avons aucune raison impérieuse de faire la fonctionnalité. Les délégués qui ont des paramètres out/ref sont relativement rares. Et l'attribution de lambdas à ces délégués est encore plus rare. Donc, c'est une fonctionnalité dont nous n'avons pas besoin, et qui ne profite presque à personne.

C# 3 était le «pôle long» de l'horaire Visual Studio; nous avons eu le plus grand nombre de jours de travail prévus pour toute équipe qui expédie un composant dans VS. Cela signifiait que tous les jours nous avons glissé l'horaire, l'ensemble division glissé. Cela a fortement découragé de consacrer du temps à des fonctions inutiles qui n'ont profité à personne. Donc le travail n'a jamais été fait. Je suis d'accord que ce serait bien d'être plus cohérent ici, mais il est peu probable que cela se produise. Nous avons beaucoup de priorités plus élevées.

Answer 2

De Eric Lippert's comment pourquoi la déclaration et l'affectation d'une variable var ne peuvent pas être séparés:

Je suis d'accord que, en principe, cela pourrait se faire , mais c'est plus compliqué en pratique que ne le laisserait supposer votre rapide esquisse. var exige non seulement qu'il y ait un initialiseur, mais aussi que l'initialiseur ne fasse pas référence à la variable. Si vous avez int M (out int), vous pouvez dire "int x = M (out x);" mais vous ne pouvez pas dire "var x = M (out x);" parce que pour faire une résolution de surcharge sur M, nous devons connaître le type de x, ce que nous essayons de comprendre. Serait-il légal de dire "var s, si (b) M (out s), sinon s = 0;" ?

Je suppose que la réponse à votre question est similaire, compte tenu, par exemple,

D a = (out var x) => x = M(out x);