Compilateur C # nécessite une nouvelle () contrainte à spécifier en dernier. Selon MSDN:
Lorsqu'il est utilisé avec d'autres contraintes, la nouvelle contrainte () doit être spécifié en dernier.
Pourquoi existe-t-il une telle restriction?
3 Réponses :
Par exemple, sur d'autres contraintes (classe par exemple), vous pouvez spécifier un constructeur pendant d'autres contraintes que vous ne pouvez pas (interfaces).
Donc, si nouveau () est arrivé en premier, alors une contrainte sur une interface, vous obtiendriez une erreur car vous ne pouvez pas avoir la nouvelle contrainte () sur l'interface.
Mais vous pouvez avoir une contrainte qu'un paramètre de type implémente une interface et a un constructeur vide, donc je ne pense pas que cet argument s'applique ici.
Oui, vous avez raison, mais vous ne seriez pas en mesure de valider que si le nouveau () est venu après la classe qui a mis en œuvre l'interface (par conséquent, mettez la nouvelle contrainte ())
N'oubliez pas que les contraintes s'appliquent au paramètre de type. Donc, il est parfaitement possible d'avoir défini la grammaire de sorte que où T: nouveau (), iterface signifie que t est un type ayant un constructeur par défaut et la mise en œuvre de l'interface IINTERFACE , les concepteurs de langue ont simplement choisi de ne pas la conception de la sorte de cette manière.
Il semble vraiment que la facilité de validation des contraintes ait peut-être été la raison réelle, je suis sûr que vous pourriez le faire dans n'importe quel ordre, mais une certaine prévisibilité rend les choses un peu plus faciles.
@Jonezy: Oui, c'est mon devinez aussi (voir ma réponse).
Désolé Jason, j'étais un peu en train de parler à / à propos de votre réponse!
Parce que la spécification le dit. Cela le dit probablement donc parce que cela fait de l'analyse des contraintes un peu plus faciles. Il y a peu de valeur pour vous permettre de spécifier les contraintes dans n'importe quel ordre et que je peux imaginer des coûts (y compris les coûts d'opportunité!) Pour la rendre possible.
Note, en fait, que la spécification ne dise pas simplement que vous devez durer la contrainte du constructeur, si vous l'avez. Il dit en fait que vous devez avoir les contraintes dans l'ordre suivant
Lorsqu'une contrainte principale est une contrainte principale qui spécifie le paramètre de type doit être un type de référence ou un type de valeur, les contraintes secondaires sont celles qui spécifient une classe de base ou des interfaces, et la contrainte de constructeur est celle qui se trouve à une discussion ici.
La section correspondante de la spécification est §10.1.5 et est définitivement utile de lire.
@empi: Lors de la rédaction d'une spécification de grammaire, j'imagine garantir un caractère unique d'un élément tout en mélangeant trois catégories de constructions linguistiques, c'est un peu un pita. Dire que cela vient en dernier est une solution simple et élégante. Vous rencontrerez les mêmes problèmes et les mêmes types de solutions lors de la définition de schémas XML.
En effet, il y a un coût pour la caractéristique proposée, avec peu d'avantages et des coûts d'opportunité. Les coûts d'opportunité ne sont pas seulement que le temps passé à faire cette fonctionnalité est retiré des autres caractéristiques dignes; C'est également que chaque fois que nous autorisons la variation d'une syntaxe, qui rend plus difficile l'étendue ou la modification de la syntaxe à l'avenir.
Yaqapd: une autre question sur la traduction d'analyse
Chaque langage de programmation a ses propres règles. La direction de l'analyse est l'une d'entre elles. Laissez-moi vous expliquer plus en détail (soyez patient). p>
Supposons que vous écriviez la fonction suivante à Pascal / Delphi: P> maintenant, la même fonction de C: P> int function Sum2Numbers (int n1, int n2)
{
return (n1+n2);
}
Cette réponse n'a pas de sens imo. Toute source pour vos revendications?
Je suppose que lors des rapports d'erreur effectifs. Il y a un si grand nombre d'erreurs possibles, en particulier lorsqu'il y a une contrainte de type de valeur.