Pourquoi les constructeurs C# ne peuvent-ils pas hériter de l'inférence de type à partir de méthodes génériques ?

Pourquoi les constructeurs C# ne peuvent-ils pas hériter de l'inférence de type à partir de méthodes génériques ?

En C#, les constructeurs n'ont pas les capacités d'inférence de type des méthodes génériques. Par exemple, dans le code suivant :

<code class="language-csharp">public class MyType<T>
{
   private readonly T field;
   public MyType(T value) { field = value; }
}

var obj = new MyType(42); // 期望类型：MyType<int></code>

Le compilateur ne peut pas déduire que obj est de type MyType<int>. Une solution consiste à utiliser une classe d'usine :

<code class="language-csharp">public class MyTypeFactory
{
   public static MyType<T> Create<T>(T value)
   {
      return new MyType<T>(value);
   }
}
var myObj = MyTypeFactory.Create(42);</code>

Cela soulève des questions sur les raisons de cette restriction.

Y a-t-il une cause profonde ?

Il n'y a aucune raison sous-jacente concluante empêchant les constructeurs de faire une inférence de type. En revanche, identifier tous les types pertinents et résoudre les surcharges entre constructeurs avec différents nombres de paramètres nécessite un algorithme complexe. De plus, pour garantir la compatibilité ascendante, les constructeurs non génériques ont priorité sur les constructeurs déduits.

Obstacles pratiques : peser le pour et le contre

Bien que l'inférence de type dans les constructeurs présente un avantage net, cela ne garantit pas nécessairement sa mise en œuvre. La viabilité d'une fonctionnalité dépend de sa valeur relative par rapport à d'autres améliorations potentielles, à l'allocation des ressources et aux problèmes de compatibilité.

Modèle d'usine : une alternative intelligente

Le modèle de méthode d'usine fournit une solution efficace au manque d'inférence de type constructeur. En introduisant une couche supplémentaire d'abstraction, l'inférence de type peut être appliquée aux méthodes d'usine pour obtenir des résultats similaires sans modifier le constructeur lui-même.

Des changements qui n'ont jamais été mis en œuvre

Bien que l'implémentation ait été envisagée pour C# 6, cette fonctionnalité proposée a finalement été supprimée de la conception finale. Le fait qu’il soit sur le point d’être adopté a mis en évidence son utilité potentielle, mais en fin de compte, d’autres priorités ont prévalu.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!