В С++ использование const везде, где только можно, является хорошим тоном.

Почему в C# нет подобного отношения к readonly? Не наблюдаю россыпей readonly на полях
типа List/Dictionary, хотя там они естественны.

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

SO_>В С++ использование const везде, где только можно, является хорошим тоном.

SO_>Почему в C# нет подобного отношения к readonly? Не наблюдаю россыпей readonly на полях
SO_>типа List/Dictionary, хотя там они естественны.

Лень писать readonly, особенно, когда пишешь код для себя/сам. Да и собственно зачем его лишний раз писать, если и так почти моментально/интуитивно понимаешь когда можно менять глобальную переменную, а когда нет. В c++, намного больше времени понадобилось бы, что бы проанализировать каждую переменную, можно ли ее менять или нет, потому и пишут везде где только можно const, что бы создать себе допольнительные ограничения — что бы меньше думать в будущем когда будет менятся код.

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

SO_>Почему в C# нет подобного отношения к readonly?

По-моему, есть. Rider заставляет писать readonly, Microsoft.CodeQuality.Analyzers тоже.

SO_>Не наблюдаю россыпей readonly на полях

Я наблюдаю, и сам рассыпаю :)

Есть редкие патологические случаи в структурах, когда readonly может неявно приводить к снижению производительности из-за defensive copy, но с введением readonly struct в язык эта проблема не так актуальна.

SO_>Почему в C# нет подобного отношения к readonly?
Потому что в С++ const даёт дофига гарантий и при этом вообще не напрягает вызывающую сторону. В C# readonly — чаще всего способ усложнить себе жизнь, без всяких гарантий что будет надёжнее или быстрее работать. Видимо, когда начинали C# вообще не понимали что такое иммутабельность и как ею пользуются (сейчас похоже понимают, но вкорячивание нужных вещей идёт со скрипом):
1) Самое главное нет понятия readonly метод. Все эти [Pure] ни о чём, потому что компилятором не проверяются. Из-за этого целый класс оптимизаций превращается в очень аккуратное отслеживание "правильно ли используется тут структура", либо неожиданные тормоза на ровном месте из-за defensive-copy. Причём у компилятора даже нету варнинга "defensive copy here" который можно было бы поставить как error и быть уверенным что случайно чего-то не испортишь.

2) Из-за того-же всякие объекты посложнее типа readonly List<T> — вообще какая-то химера. Ссылка на список иммутабельна, сам список нет. IReadonlyList<T> не предлагать.

3) Нет возможности например вызывающему методу использовать структуру или класс как мутабельные, но передавать на обработку (допустим в многопоточный алгоритм) как readonly и чтобы дальше компилятор следил что у объекта вызываются только readonly методы (которых нет).

4) Нету val/let/readonly var и readonly аргументов — компилятор не следит и не даёт по рукам за вызов мутабельных методов. И это при том что компилятор сам мог бы выводить мутабельность/иммутабельность методов и студия могла бы сама расставлять эти readonly.

5) В C++ ради скорости или чего-то ещё можно наделать перегрузок которые отличаются только константностью аргументов. В C# только-только появилось понятие in-аргумента, и см.1 почему оно далеко не всегда хорошо.

6) Наконец пользоваться in и readonly в C# просто неудобно. Вот это вот:

readonly struct S { } //ну очень иммутабельная структура

static void M1(in S s) => Console.WriteLine("in s");
static void M1(S s) => Console.WriteLine("mutable s");
        
static readonly S x = default;

static void Main(string[] args)
{
  S d = default;

  M1(d);
  M1(x);
}

Прям вопрос для собеседования — какую же перегрузку выберет компилятор. Подсказка — будет выбирать самую говенную из возможных (полная противоположность C++). Никакого автовыбора оптимальной перегрузки, когда C++ отлично выбирает const &arg — не будет. Хочется передать как const& вызываем метод так: M1(in d); и никак иначе. Readonly структура или нет, большая или маленькая, программист не желающий индусить должен страдать.

Представь как много людей пользовалось бы const в C++ если бы нужно было писать const не только в самом методе, но ещё и перед каждым параметром при вызове этого метода. Примерно так: auto c = max(const &a, const &b) // больше констов богу констов

В итоге readonly структуры — не решение а затычка. Лучше чем вообще ничего, но хуже чем нормальное отслеживание иммутабельности на уровне компилятора как сделано с const в C++.

Некоторые проблемы находит ErrorProne.NET.Structs от Сергея Тепляков, но надо больше для того чтобы в C# readonly стал стилем хорошего программиста также как в C++ const.

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

SO_>В С++ использование const везде, где только можно, является хорошим тоном.

SO_>Почему в C# нет подобного отношения к readonly? Не наблюдаю россыпей readonly на полях
SO_>типа List/Dictionary, хотя там они естественны.

Это так же глупо, как писать на бетоне "не копать!". Да никто и не собирался копать, зачем ещё и надпись?? Так же и с алгоритмами — если у меня список и я тупо добавляю в него элементы, зачем мне ещё и защита от убивания списка? И если быть до конца параноиками, а что если у меня спиок не имеет права удалять элементы? Мне что, помечать список ещё и AddOnly?

Кроме того, и сам компилятор вполне может справиться с задачей "кто тут у нас самый ридонли" — зачем мне ещё и код засирать?

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

SO_>Почему в C# нет подобного отношения к readonly? Не наблюдаю россыпей readonly на полях
SO_>типа List/Dictionary, хотя там они естественны.

Задай вопрос авторам кода, в котором ты не наблюдаешь.

Q>Есть редкие патологические случаи в структурах, когда readonly может неявно приводить к снижению производительности из-за defensive copy

Можете поподробней про это рассказать?или порекомендую, что почитать

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

Q>>Есть редкие патологические случаи в структурах, когда readonly может неявно приводить к снижению производительности из-за defensive copy
IB>Можете поподробней про это рассказать?или порекомендую, что почитать

Jon Skeet: Micro-optimization: the surprising inefficiency of readonly fields
@SergeyT.: Avoiding struct and readonly reference performance pitfalls with ErrorProne.NET
Bill Wagner et al.: Write safe and efficient C# code

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

SO_>В С++ использование const везде, где только можно, является хорошим тоном.

SO_>Почему в C# нет подобного отношения к readonly? Не наблюдаю россыпей readonly на полях
SO_>типа List/Dictionary, хотя там они естественны.

Я не пишу, за меня его студия сама пишет, когда я необъявленное поле начинаю использовать. Давно есть расширения вроде Roslynator, которые такие мелкие задачи автоматизируют.

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

V>Я не пишу, за меня его студия сама пишет, когда я необъявленное поле начинаю использовать. Давно есть расширения вроде Roslynator, которые такие мелкие задачи автоматизируют.

Я однажды машинально написал readonly рядом со SpinLock — вот это было весело

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

SO_>В С++ использование const везде, где только можно, является хорошим тоном.

SO_>Почему в C# нет подобного отношения к readonly? Не наблюдаю россыпей readonly на полях
SO_>типа List/Dictionary, хотя там они естественны.

Дело в том, что readonly в C# действует только на верхнем уровне,
для ссылочных типов таким образом можно лишь защитить ссылку на список, но не значения.
Можете прочитать об этом у Андрей Александреску в книге язык программирования Ди.
Там есть такая фраза, что если ваш модификатор не защищает объект на всю глубину от изменений,
то он имеет силу комментария. К сожалению, архитектурно, C# не защищает поля любой вложенности от изменения.
Думаю, поэтому никто и не пользуется, т.к. защита очень слабая, хотя я стараюсь все же помечать этим модификатором,
т.к. это упрощает понимание кода.

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

AA>Думаю, поэтому никто и не пользуется

В смысле, никто не пользуется? Все пользуются. В этом легко убедиться на ГитХабе, полистав код широко используемых проектов.

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

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

AA>>Думаю, поэтому никто и не пользуется

Q>В смысле, никто не пользуется? Все пользуются. В этом легко убедиться на ГитХабе, полистав код широко используемых проектов.

Согласен, написал в контексте вопроса, смысл ограничения приходит с опытом.
Вообще, в C# 7 имеет 3 основных ограничения:
private readonly
(private) const
T P {get;}

Однако, как я уже заметил, эти модификаторы имеют смысл для простых типов и ссылок, даже поля структур если их тоже не пометить
будут изменяемыми, что конечно не хорошо, т.к. если требуется полную неизменяемость придется пометить все поля, но встроенные типы так не защищить(в отличии от D в котором
подобные модификаторы делаю весь граф по ссылке иммутабельным).

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

K>Это так же глупо, как писать на бетоне "не копать!". Да никто и не собирался копать, зачем ещё и надпись??

Только не на бетоне, а на песке. Под которым куча говна.

И это ты сейчас не собирался, а потом сверху насыпешь резиновой крошки, забудешь про песок, и закажешь свой участок, вместе с земляным, строителям. Которые будут ставить забор.

K>Кроме того, и сам компилятор вполне может справиться с задачей "кто тут у нас самый ридонли" — зачем мне ещё и код засирать?

мдаа.. наивный паренек )

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

SO_>В С++ использование const везде, где только можно, является хорошим тоном.

SO_>Почему в C# нет подобного отношения к readonly? Не наблюдаю россыпей readonly на полях
SO_>типа List/Dictionary, хотя там они естественны.

Очень даже пользуются. На код ревью пинаю если пропускают. Быдлокодерам ясно дело по барабану все это.