Por que o C # não suporta const em um nível de classe / método?
Eu tenho me perguntado por um tempo porque C # não suportaconst
em uma classe ou um nível de método. Eu sei que Jon Skeet queria suporte para a imutabilidade por um longo tempo, e reconheço que usar a sintaxe C ++ da função const poderia ajudar nisso. Ao adicionar uma palavra-chave const em um nível de classe, teríamos total suporte.
Agora, minha pergunta é, qual é a razão para a equipe de C # não ter desenvolvido esse tipo de suporte?
Eu imagino que tudo poderia ser criado com uma verificação em tempo de compilação ou através de atributos, sem precisar alterar o CLR. Eu não me importo que o código seja capaz de substituir o comportamento const através da reflexão.
Imagina isto:
<code>const class NumberContainer { public int Number { get; } } </code>
.. Tal classe só poderia ser preenchida em tempo de construção, então precisaríamos de um construtor para receber um int.
Outro exemplo é const em um nível de método:
<code>public int AddNumbers(NumberContainer n1, NumberContainer n2) const { return n1.Number + n2.Number; } </code>
Os métodos de nível de constância não devem poder alterar o estado em sua própria classe ou instâncias de tipos de referência passados para eles. Além disso, as funções de nível de const apenas podem invocar outras funções de nível de const no seu escopo.
Eu não tenho certeza se lambdas e delegados fariam tudo muito difícil (ou impossível) de conseguir, mas tenho certeza que alguém com mais experiência em linguagem e design de compilador poderia me dizer.
Como Steve B apontou nos comentários, a existência dereadonly
torna as coisas um pouco mais complexas, como const ereadonly
estão perto do mesmo duranteruntime
, masreadonly
valores não podem ser determinados durante o tempo de compilação. Eu acho que poderíamos terconst
ereadonly
nível, mas isso pode ser muito confuso?
Então, qual é a razão para não implementar isso? Preocupações de usabilidade (entender a constância em C ++ geralmente é muito difícil para novos usuários), preocupações com design de linguagem (não podem ser feitas) ou simplesmente preocupações prioritárias (os dias do burburinho de imutabilidade acabaram) ..?