Чому параметри const не дозволені в C #?

Це виглядає дивно, особливо для розробників C ++. У C ++ ми позначали параметр як constдля того, щоб бути впевненим, що його стан не буде змінено у методі. Існують також інші специфічні причини C ++, наприклад, проходження const ref, щоб пройти посилання і бути впевненим, що стан не буде змінено. Але чому ми не можемо позначити як параметр методу const у C #?

Чому я не можу оголосити свій метод таким чином?

    ....
    static void TestMethod1(const MyClass val)
    {}
    ....
    static void TestMethod2(const int val)
    {}
    ....

На додаток до інших хороших відповідей, я додам ще одну причину, чому не можна вводити в C # стильність у C #. Ти сказав:

ми позначаємо параметр const, щоб бути впевненим, що його стан не буде змінено у методі.

Якби фактично це робив Конст, це було б чудово. Конст цього не робить. Конст - брехня!

Const не дає жодної гарантії, яку я фактично можу використовувати. Припустимо, у вас є метод, який вимагає рівноваги. Є два автори коду: людина, яка пише абонента, і особа, яка пише абонента . Автор виклику змусив метод прийняти const. Що можна вважати двома авторами щодо об'єкта?

Нічого. Оголошення вільне відкинути const та мутувати об’єкт, тому абонент не має гарантії, що виклик методу, який приймає const, насправді не буде його мутувати. Аналогічно, замовник не може припустити, що вміст об'єкта не змінюватиметься протягом всієї дії виклику; callee може викликати якийсь мутуючий метод на non-const псевдонімі const об'єкта, і тепер так званий об'єкт const змінився .

Const у стилі C не дає гарантії, що об'єкт не зміниться і тому буде зламаний. Тепер, у C вже є система слабкого типу, в якій ви можете зробити реінтерпретовану передачу подвійних в int, якщо цього дуже хочете, тому не повинно бути сюрпризом, що у неї є система слабкого типу і щодо const. Але C # був розроблений для того, щоб мати гарну систему типів, систему типів, де, коли ви говорите "ця змінна містить рядок", що змінна насправді містить посилання на рядок (або null). Ми абсолютно не хочемо вводити модифікатор типу "const" у тип типу в систему типів, оскільки не хочемо, щоб система типів була брехнею . Ми хочемо, щоб система типів була міцною, щоб ви могли правильно міркувати про свій код.

Const в C - це орієнтир ; це в основному означає "ви можете мені довіряти, щоб не намагатися мутувати цю річ". Це не повинно бути в системі типів ; речі в системі типів повинні бути фактом про об'єкт, про який ви можете міркувати, а не керівництвом щодо його використання.

Тепер не зрозумійте мене неправильно; тільки те, що const в C глибоко порушений, не означає, що вся концепція марна. Що я хотів би побачити - це фактично правильна і корисна форма анотації "const" в C #, примітка, яку можуть використовувати і люди, і компілятори, щоб допомогти їм зрозуміти код, і що час виконання може використовуватись для таких дій, як автоматична паралелізація та інші розширені оптимізації.

Наприклад, уявіть, якби ви могли «намалювати поле» навколо лука коду і сказати «Я гарантую, що ця команда коду не виконує жодних мутацій до будь-якого поля цього класу» таким чином, щоб це міг перевірити компілятор. Або намалюйте поле, в якому сказано, що "цей чистий метод мутує внутрішній стан об'єкта, але ніяк не спостерігається поза коробкою". Такий об'єкт не може бути безпечно багатопотоковим автоматично, але він може автоматично запам'ятовуватися . Існують всілякі цікаві примітки, які ми можемо застосувати до коду, які дозволять отримати багаті оптимізації та глибше розуміння. Ми можемо зробити набагато краще, ніж слабкі анотації в стилі С.

Однак наголошую, що це лише спекуляція . Ми не маємо твердих планів включити подібну особливість у будь-яку гіпотетичну майбутню версію C #, якщо вона є навіть такою, про яку ми не оголосили так чи інакше. Мені б хотілося це побачити, і те, на що може знадобитися подальший акцент на багатоядерних обчисленнях, але жодне з цього не повинно розглядатися як передбачення або гарантія будь-якої особливості чи майбутнього напрямку для C #.

Тепер, якщо ви хочете - це лише анотація до локальної змінної, яка є параметром, який говорить, що "значення цього параметра не змінюється протягом усього методу", то, звичайно, це було б легко зробити. Ми можемо підтримувати локальні локальні пристрої та параметри, які були б ініціалізовані один раз, і помилка часу компіляції, щоб змінити метод. Змінна, оголошена оператором "using", вже така локальна; ми можемо додати необов’язкове примітку до всіх локальних пристроїв та параметрів, щоб змусити їх діяти як "використання" змінних. Він ніколи не був дуже пріоритетним, тому він ніколи не був реалізований.

Однією з причин того, що в C # немає коректності коректності, є те, що він не існує на рівні виконання. Пам'ятайте, що C # 1.0 не мав жодної функції, якщо вона не була частиною часу виконання.

І кілька причин, чому CLR не має поняття коректності коректності, наприклад:

1. Це ускладнює час виконання; до того ж у JVM його також не було, і CLR в основному почався як проект зі створення часу, схожого на JVM, а не на C ++ - як час виконання.
2. Якщо на рівні виконання є коректність коректності, то в BCL має бути правильність const, інакше ця функція майже безглузда, що стосується .NET Framework.
3. Але якщо BCL вимагає правильності const, кожна мова, що перебуває поверх CLR, повинна підтримувати правильність const (VB, JavaScript, Python, Ruby, F # тощо). Це не відбудеться.

Правильність конкуренції - це майже мовна особливість, наявна лише у C ++. Таким чином, це зводиться до тієї ж аргументації щодо того, чому CLR не вимагає перевірених винятків (що є лише мовою Java).

Крім того, я не думаю, що ви можете запровадити таку функціональну систему системи в керованому середовищі, не порушуючи зворотної сумісності. Тож не розраховуйте на правильність const, коли ви входите у світ C #.

Я вважаю, що є дві причини C # не коректна.

Перший - зрозумілість . Мало хто з програмістів на C ++ розуміє правильність конкуренції. Простий приклад const int argмилий, але я також бачив char * const * const arg- постійний вказівник на постійні вказівники на непостійні символи. Правильність конкурентоспроможності покажчиків на функції - це зовсім новий рівень затуплення.

Друге - тому, що аргументи класу - це посилання, передані за значенням. Це означає, що вже існує два рівні стійкості, без явно чіткого синтаксису . Аналогічним каменем спотикання є колекції (і колекції колекцій тощо).

Правильність конкуренції є важливою частиною системи типу C ++. Теоретично це може бути додано до C # як те, що перевіряється лише під час компіляції (його не потрібно додавати в CLR і не впливатиме на BCL, якщо б не було включено поняття методів-членів const) .

Однак я вважаю, що це малоймовірно: другу причину (синтаксис) було б досить важко вирішити, що зробило б першу причину (зрозумілістю) ще більшою проблемою.

constозначає "константа часу компіляції" в C #, а не "лише для читання, але можливо, може бути змінена іншим кодом", як у C ++. Приблизний аналог C ++ constу C # є readonly, але це стосується лише полів. Крім цього, у C # взагалі немає поняття правильності const.

Обґрунтування важко сказати напевно, тому що існує маса потенційних причин, але, на мою думку, було б бажання зберегти мову першою і найголовнішою, і невизначені переваги впровадження цієї другої.

Це можливо, оскільки C # 7.2 (грудень 2017 року з Visual Studio 2017 15.5).

Тільки для структур та основних типів ! , не для членів класів.

Ви повинні використовувати, inщоб надіслати аргумент як вхід за посиланням. Побачити:

Дивіться: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/in-parameter-modifier

Для вашого прикладу:

....
static void TestMethod1(in MyStruct val)
{
    val = new MyStruct;  // Error CS8331 Cannot assign to variable 'in MyStruct' because it is a readonly variable
    val.member = 0;  // Error CS8332 Cannot assign to a member of variable 'MyStruct' because it is a readonly variable
}
....
static void TestMethod2(in int val)
{
    val = 0;  // Error CS8331 Cannot assign to variable 'in int' because it is a readonly variable
}
....