Комментарии 14
Больше статей богу статей ?
Разбирать модификатор из версии языка 7.2 в 25 году это сильно.
Там, где нужна передача жирной структуры по ссылке и мутации нет, на замену in давно пришел ref readonly - ругается на передачу по значению в компайл тайме.
И в отличие от in гарантированно избегает defensive copy. А еще сейчас появился дополнительный scoped. Как-то все это выкинуть из контекста совсем не круто для статьи про современный сишарп.
Вообще-то - нет, не избегает. Ровно такое же поведение с т.з. defensive copy.
https://stackoverflow.com/a/78050832/921054
Разница лишь в warning'ах
Защита от мутаций. Любая попытка изменить поле внутри метода — ошибка компиляции.
Враньё. Наружу, конечно, изменения не уйдут. Но, если по in передать экземпляр класса, то внутри метода меняй сколько угодно - ни чего тебе компилятор не скажет.
Не туда
Так Вам ссылку передали, вам её запрещено менять, а не поля класса доступные оп ссылке. Классы передаются по ссылке, Структуры по значению, и in в value типах как раз эмулирует поведение классов, утрировано.
Любая попытка изменить поле внутри метода — ошибка компиляции.
Почему "поле"? Может, тут надо слово "поле" поменять на "параметр"?
Нет, там речь про поля структуры.
В том то и дело, что In ни к полям структуры, ни к полям класса отношения не имеет.
Термин defensive copy применительно к не-ридонли структурам о чём-нибудь говорит?
in на этапе компиляции уже не даст изменять поля структуры. На класс ему пофигу, он всегда по ссылке передаётся.
Почитайте как передаются параметры в функции, там всё подробно расписано и даже на русском, я не программист, и то понял.
in-аргументы в C#: чем они отличаются от ref, out, и где реально полезны