Почему параметры константы не позволяются в C#?

В дополнение к другим хорошим ответам, я добавлю еще одну причину, почему не стоит вводить в C# константность в стиле C. Вы сказали:

мы помечаем параметр как const, чтобы быть уверенными, что его состояние не будет изменено в методе.

Если бы const действительно это делала, это было бы замечательно. Const этого не делает. const - это ложь!

Const не дает никакой гарантии, которую я мог бы реально использовать. Предположим, у вас есть метод, который принимает const. Есть два автора кода: человек, пишущий caller, и человек, пишущий callee. Автор вызывающей стороны сделал метод принимающим const. Что оба автора могут предположить неизменным в объекте?

Ничего. Вызывающий может отбросить const и изменить объект, поэтому у вызывающего нет гарантии, что вызов метода, принимающего const, не приведет к его изменению. Аналогично, вызывающий не может предположить, что содержимое объекта не изменится во время действий вызывающего; вызывающий может вызвать какой-нибудь мутирующий метод на не const псевдониме объекта const, и теперь так называемый объект const изменился.

const в стиле C не дает гарантии, что объект не изменится, и поэтому является нерабочим. Итак, в C уже есть слабая система типов, в которой вы можете сделать переинтерпретацию двойки в int, если очень захотите, поэтому не стоит удивляться, что в нем есть слабая система типов и в отношении const. Но C# был разработан, чтобы иметь хорошую систему типов, систему типов, в которой, когда вы говорите "эта переменная содержит строку", переменная действительно содержит ссылку на строку (или null). Мы совершенно не хотим вводить в систему типов модификатор "const" в стиле C, потому что мы не хотим, чтобы система типов была ложью. Мы хотим, чтобы система типов была сильной, чтобы вы могли правильно рассуждать о своем коде.

Const в C - это руководство; в основном это означает "вы можете доверять мне, что я не буду пытаться мутировать эту вещь". Этого не должно быть в системе типов; вещи в системе типов должны быть фактом об объекте, о котором вы можете рассуждать, а не руководством по его использованию.

Не поймите меня неправильно; то, что const в C глубоко сломана, не означает, что вся концепция бесполезна. Я бы хотел увидеть в C# некую правильную и полезную форму аннотации "const", аннотацию, которую и люди, и компиляторы могли бы использовать для понимания кода, и которую среда выполнения могла бы использовать для таких вещей, как автоматическая паралеллизация и другие продвинутые оптимизации.

Например, представьте, если бы вы могли "нарисовать рамку" вокруг куска кода и сказать: "Я гарантирую, что этот кусок кода не выполняет никаких мутаций ни с одним полем этого класса" таким образом, чтобы компилятор мог это проверить. Или нарисуйте рамку с надписью "этот чистый метод изменяет внутреннее состояние объекта, но не так, чтобы это было заметно за пределами рамки рамки". Такой объект не может быть безопасно многопоточным автоматически, но он может быть автоматически мемоизирован. Существуют всевозможные интересные аннотации, которые мы могли бы поместить в код, что обеспечило бы богатую оптимизацию и более глубокое понимание. Мы можем сделать гораздо больше, чем слабая аннотация const в стиле C.

Однако я подчеркиваю, что это всего лишь спекуляция. У нас нет твердых планов по включению подобной функции в какую-либо гипотетическую будущую версию C#, если таковая вообще существует, о чем мы не объявляли ни в том, ни в другом случае. Это то, что я хотел бы увидеть, и то, чего может потребовать грядущий акцент на многоядерных вычислениях, но все это ни в коем случае не должно быть истолковано как предсказание или гарантия какой-либо конкретной функции или будущего направления развития C#.

Итак, если вы хотите просто аннотацию к локальной переменной, которая является параметром и говорит: "Значение этого параметра не меняется в течение всего метода", то, конечно, это легко сделать. Мы могли бы поддерживать локальные переменные "readonly" и параметры, которые инициализируются один раз, а их изменение в методе будет сопровождаться ошибкой компиляции. Переменная, объявленная оператором "using", уже является такой локалью; мы могли бы добавить необязательную аннотацию ко всем локалям и параметрам, чтобы они вели себя как переменные "using". Это никогда не было очень приоритетной функцией, поэтому она так и не была реализована.