En plus des autres bonnes réponses, j'ajouterai encore une autre raison pour laquelle ne pas mettre la constness de style C dans C #. Tu as dit:
nous marquons le paramètre comme const afin d'être sûr que son état ne sera pas changé dans method.
Si const faisait ça, ce serait génial. Const ne fait pas ça. Le const est un mensonge!
Const ne fournit aucune garantie que je puisse réellement utiliser. Supposons que vous ayez une méthode qui accepte une chose const. Il existe deux auteurs de code: la personne qui écrit l' appelant et la personne qui écrit l' appelé . L'auteur de l'appelé a fait prendre à la méthode un const. Qu'est-ce que les deux auteurs peuvent supposer est invariant pour l'objet?
Rien. L'appelé est libre de rejeter le const et de muter l'objet, de sorte que l'appelant n'a aucune garantie que l'appel d'une méthode qui prend un const ne le mute pas. De même, l'appelé ne peut pas supposer que le contenu de l'objet ne changera pas tout au long de l'action de l'appelé; l'appelé pourrait appeler une méthode de mutation sur un alias non const de l'objet const, et maintenant le soi-disant objet const a changé .
Le const de style C n'offre aucune garantie que l'objet ne changera pas et qu'il est donc cassé. Maintenant, C a déjà un système de type faible dans lequel vous pouvez réinterpréter le cast d'un double en un int si vous le souhaitez vraiment, il ne devrait donc pas être surprenant qu'il ait également un système de type faible par rapport à const. Mais C # a été conçu pour avoir un bon système de type, un système de type où lorsque vous dites "cette variable contient une chaîne" que la variable contient en fait une référence à une chaîne (ou null). Nous ne voulons absolument pas mettre un modificateur "const" de style C dans le système de types parce que nous ne voulons pas que le système de types soit un mensonge . Nous voulons que le système de typage soit fort pour que vous puissiez raisonner correctement sur votre code.
Const en C est une ligne directrice ; cela signifie essentiellement "vous pouvez me faire confiance pour ne pas essayer de muter cette chose". Cela ne devrait pas être dans le système de types ; les éléments du système de types doivent être un fait sur l'objet sur lequel vous pouvez raisonner, et non un guide pour son utilisation.
Maintenant, ne vous méprenez pas; ce n'est pas parce que const en C est profondément brisé que tout le concept est inutile. Ce que j'aimerais voir, c'est une forme d'annotation "const" réellement correcte et utile en C #, une annotation que les humains et les compilateurs pourraient utiliser pour les aider à comprendre le code, et que le runtime pourrait utiliser pour faire des choses comme la paralellisation automatique et autres optimisations avancées.
Par exemple, imaginez si vous pouviez "dessiner une boîte" autour d'un morceau de code et dire "Je vous garantis que ce morceau de code n'effectue aucune mutation dans aucun champ de cette classe" d'une manière qui pourrait être vérifiée par le compilateur. Ou dessinez une boîte qui dit "cette méthode pure mute l'état interne de l'objet mais pas d'une manière qui soit observable en dehors de la boîte". Un tel objet ne peut pas être automatiquement multi- threadé en toute sécurité, mais il peut être mémorisé automatiquement . Il y a toutes sortes d'annotations intéressantes que nous pourrions mettre sur le code qui permettraient des optimisations riches et une compréhension plus profonde. Nous pouvons faire bien mieux que la faible annotation const de style C.
Cependant, je souligne qu'il ne s'agit que de spéculation . Nous n'avons pas l'intention de mettre ce type de fonctionnalité dans une future version hypothétique de C #, s'il y en a une, que nous n'avons pas annoncée d'une manière ou d'une autre. C'est quelque chose que j'aimerais voir, et quelque chose que l'accent à venir sur l'informatique multicœur pourrait exiger, mais rien de tout cela ne devrait être interprété en aucune façon comme une prédiction ou une garantie d'une fonctionnalité particulière ou d'une direction future pour C #.
Maintenant, si ce que vous voulez est simplement une annotation sur la variable locale qui est un paramètre qui dit "la valeur de ce paramètre ne change pas tout au long de la méthode", alors, bien sûr, ce serait facile à faire. Nous pourrions prendre en charge les paramètres locaux et les paramètres "en lecture seule" qui seraient initialisés une fois, et une erreur de compilation pour changer la méthode. La variable déclarée par l'instruction "using" est déjà un tel local; nous pourrions ajouter une annotation facultative à toutes les variables locales et paramètres pour les faire agir comme des variables "utilisant". Cela n'a jamais été une fonctionnalité très prioritaire, donc elle n'a jamais été implémentée.