Question

spécification langage C # décrit l'inférence de type dans la section §7.5.2. Il y a un détail dans ce que je ne comprends pas. Prenons le cas suivant:

// declaration
void Method<T>(T obj, Func<string, T> func);

// call
Method("obj", s => (object) s);

Les deux Microsoft et Mono C # compilateurs correctement déduisent T = object, mais ma compréhension de l'algorithme dans la spécification rapporterait T = string puis échouer. Voici comment je comprends:

La première phase

  • Si Ei est une fonction anonyme, une inférence de type de paramètre explicite (§7.5.2.7) est fabriqué à partir Ei à Ti

    ? n'a pas d'effet, parce que l'expression lambda n'a pas de paramètres explicites types. Droit?

  • Sinon, si Ei a un type U et xi est un paramètre de valeur puis a inférence limite inférieure U est fabriqué à partir de Ti.

    ? le premier paramètre est de string de type statique, donc cela ajoute string aux bornes inférieures pour T, droit?

La deuxième phase

  • Tous non fixé variables de type Xi qui ne le font pas dépendent de (§7.5.2.5) tout Xj sont fixés (§7.5.2.10).

    ? T est non fixée; T ne dépend pas de quoi que ce soit ... si T devrait être fixé, à droite?

Fixation §7.5.2.11

  • L'ensemble des types de candidats Uj commence comme l'ensemble de tous les types dans l'ensemble des limites pour Xi.

    ? {string (borne inférieure)}

  • Nous examinons ensuite chaque Xi pour lié à son tour: [...] Pour chaque borne inférieure U de Xi tous les types Uj auxquels il n'y a pas une conversion implicite de U sont retirées de l'ensemble des candidats. [...]

    ? ne supprime rien de l'ensemble candidat, droit?

  • Si parmi les types de candidats restants Uj il y a un type unique V à partir de laquelle il y a une conversion implicite à tous les autres types de candidats, alors Xi est fixé à V.

    ? Comme il n'y a qu'un seul type de candidat, c'est vacuously vrai, si Xi est fixé à string. Droit?


Alors, où vais-je tort?

Était-ce utile?

La solution

MISE À JOUR: Mon enquête initiale sur le bus ce matin était incomplète et erronée. Le texte de la première spécification de phase est correcte. La mise en œuvre est correcte.

La spécification est erronée en ce qu'elle obtient l'ordre des événements mal dans la deuxième phase. Nous devrions nous précisons que faire des inférences de type de sortie avant nous fixer les paramètres non-dépendants.

L'homme, ce genre de choses est compliquée. Je l'ai réécrit cette section des fois plus que spec je me souvienne.

J'ai vu ce problème avant, et je me souviens distinctement faire des révisions telles que la « variable de type » terme incorrect a été remplacé partout avec « paramètre de type ». (Paramètres de type ne sont pas des emplacements de stockage dont le contenu peut varier, donc il n'a pas de sens de les appeler des variables.) Je pense en même temps, je remarquai que la commande était erronée. Probablement ce qui est arrivé a été accidentellement nous avons livré une ancienne version de la spécification sur le web. Mes excuses.

Je vais travailler avec Mads pour obtenir la spécification mise à jour pour correspondre à la mise en œuvre. Je pense que devrait aller quelque chose comme la formulation correcte de la deuxième phase suivante:

  
      
  • Si aucun paramètre de type non fixés existent puis tapez l'inférence réussit.
  •   
  • Dans le cas contraire, s'il existe un ou plusieurs arguments avec Ei   paramètre type Ti correspondant de telle sorte que   le type de sortie Ei de type Ti contenant au moins une non fixée   Paramètre Type Xj, et   aucun des types d'entrée Ei de type Ti contient des non fixée   Paramètre Type Xj,   puis une inférence de type de sortie est composé de tous ces Ei de Ti.
  •   
     

Si oui ou non l'étape précédente en fait une inférence, nous   doit maintenant fixer au moins un paramètre de type, comme suit:

     
      
  • S'il existe un ou plusieurs paramètres de type Xi tels que   Xi est non fixée, et   Xi a un ensemble non vide de limites, et   Xi ne dépend pas d'une Xj   puis chacun de ces Xi est fixe. Si une opération de fixation échoue   inférence de type échoue.
  •   
  • Sinon, s'il existe un ou plusieurs paramètres de type Xi tels que   Xi est non fixée, et   Xi a un ensemble non vide de limites, et   il y a au moins un type paramètre qui dépend de Xj Xi   puis chacun de ces Xi est fixe. Si une opération de fixation échoue   inférence de type échoue.
  •   
  • Dans le cas contraire, nous ne pouvons faire des progrès et il y a   paramètres non fixées. L'inférence de type échoue.
  •   
     

Si l'inférence de type ni ne réussit ni alors la deuxième phase est répétée.

L'idée ici est que nous voulons nous assurer que l'algorithme ne va jamais dans une boucle infinie. A chaque répétition de la deuxième phase, il réussit soit, échoue, ou fait des progrès. Il ne peut peut-boucle plus de fois qu'il y a des paramètres de type à fixer à des types.

Merci d'avoir attiré mon attention.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top