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

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

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

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

Из-за этого хочется вообще никогда не использовать "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;
}

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

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

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

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

Из-за этого хочется вообще никогда не использовать "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;
}