Здравствуйте, AlexRK, Вы писали:

ARK>>>Было бы четкое разделение
НС>>В чем профит?

ARK>Снижение когнитивной нагрузки. Видишь рекорд — все, ты сразу знаешь, что наломать с ним дров нельзя. Индус Вася не сможет туда завтра добавить мутабельное поле и у тебя где-то в глубине не сломается хеш-таблица, как в примере выше. Меньше обращаешь внимания на это.

В этом плане, еще более скользкая конструкция — "in" параметры. В этом примере, если написали "in", чтобы сэкономить на одном клонировании структуры(а больше и незачем его использовать), то вместо этого получаем 1 млрд клонирований.
Достаточно не заметить readonly. Или кто-то удалит readonly, то потом уже этот баг никогда не найдут.
Назвали это "защитная копия"... Тут должна быть строго ошибка компилятора(ну хотя бы warning), т.к. если создаются "защитные копии", то in вообще уже не нужен — без него хоть будет только одно клонирование.
А лучше бы — компилятор создавал только одну защитную копию, оно будет работать как — неявно убрали "in", если есть доступ к не readonly property.

Из-за этого хочется вообще никогда не использовать "in". Лучше "ref" — он не накосячит с защитными копиями.

struct S
{
    public S(int i) { Prop = i; }
    public /*readonly*/ int Prop { get; }
}

static int Func(in S p)
{
    int sum = 0;
    for (int i = 0; i < 1000_000_000; i++) 
        sum = p.Prop;
    return sum;
}