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

V>>В шарпе для такого сценария есть отдельно иммутабельный аналог map, и отдельно мутабельный builder для него.
V>>В С++ не потребовалось создавать две сущности.
·>Именно, то же самое на шарпах делается с помощью интерфейса.

Интерфейсы и в плюсах доступны.
И прочие GOF-трюки, где иммутабельность может быть св-вом объекта, а может быть адаптером-view.

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


·>А две сущности в C++ тоже есть, просто неявно. Вместо явного интерфейса делается пара const- и просто-методов.

Так мы только выразительность языков и обсуждаем.


·>Константные объекты появляются не магически, а в определениях соответствующих полей и методов.

И в правилах языка, где константные методы можно вызывать у неконстантного объекта, а наоборот нет.

Например, св-во size() (count, amount и т.д.) определены как const, соответственно, описаны однажды для константного и неконстантного объекта.
И всё это продолжает работать в таких сценариях:

template<typename T>
void const logCollection(const T & collection) { ... }

// мутабельный объект
auto cl = makeColllection();

auto size = cl.size(); // закешировали размер
logCollection(cl); // отдали куда-то по константной ссылке

for(size_t i = 0; i < size; i++) // незачем запрашивать размер коллекции заново

V>>Этот сценарий может возникнуть не только вокруг иммутабельного map, где в шарпе постелили соломку, а вообще везде.
·>И там и там надо вводить два типа. Ведь T и const T это тоже разные типы.

Да.
Но описание типа программистом — одно.


V>>Собсно, только об этом и говорится в обсуждении (многократно по кругу) — что практически любой мутабельный тип можно использовать в т.ч. в иммутабельных сценариях.
·>"Практически" в том смысле если для типа правильно спроектирован const подтип. Ровно та же петрушка, что и с интерфейсом.

Разумеется.
Например, в шарпе интерфейс IEnumerator имеет read-only св-во Current.

Т.е., итераторы на интерфейсах сделаны не только потому что невозможно было накрутить логику как в плюсах через begin/end (в нынешнем шарпе уже можно сделать достаточно близко к плюсовомоу подходу, получив дешевизну), но еще потому что ДРУГОЙ интерфейс обеспечивает ДРУГУЮ семантику. В данном случае IEnumerator — это read-only семантика, т.е. употребима к мутабельным и немутабельным типам.

А вот если речь должна идти про сами типы-коллекции, то появляются пары Span/ReadOnlySpan, Memory/ReadOnlyMemory и т.д.

И это еще в шарпе по-лёгкoму, т.к. язык позволяет определять операторы преобразования, поэтому смогли определить неявное конструирование ReadOnly-версий из мутабельных.
В джаве пришлось бы делать двойную работу, окучивая каждую пару.


V>>Остальные сценарии, когда мутабельный объект подаётся по константной ссылке — это просто удобные гарантии, т.к. после вызова метода с таким аргументом ты можешь в коде рассуждать о том, что целевой объект в результате вызова некоей ф-ии с им-аргументом, не изменился.
·>Аналог final.

Не, final-метод в джаве обозначает другое.
Тут аналог readonly-метода в шарпе, но там оно допустимо только для методов структур.
Для GC-классов нет такой возможности.

Но в случае структур, да, шарп уже позволяет повторять семантику C++.


·>Суть моего тезиса в том, что семантика const в других ЯП выражается тоже, просто через другие механизмы языка.

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

V>>В шарпе для такого сценария есть отдельно иммутабельный аналог map, и отдельно мутабельный builder для него.
V>>В С++ не потребовалось создавать две сущности.
·>Именно, то же самое на шарпах делается с помощью интерфейса.

Интерфейсы и в плюсах доступны.
И прочие GOF-трюки, где иммутабельность может быть св-вом объекта, а может быть адаптером-view.

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


·>А две сущности в C++ тоже есть, просто неявно. Вместо явного интерфейса делается пара const- и просто-методов.

Так мы только выразительность языков и обсуждаем.


·>Константные объекты появляются не магически, а в определениях соответствующих полей и методов.

И в правилах языка, где константные методы можно вызывать у неконстантного объекта, а наоборот нет.

Например, св-во size() (count, amount и т.д.) определены как const, соответственно, описаны однажды для константного и неконстантного объекта.
И всё это продолжает работать в таких сценариях:

template<typename T>
void const logCollection(const T & collection) { ... }

// мутабельный объект
auto cl = makeColllection();

auto size = cl.size(); // закешировали размер
logCollection(cl); // отдали куда-то по константной ссылке

for(size_t i = 0; i < size; i++) // незачем запрашивать размер коллекции заново

V>>Этот сценарий может возникнуть не только вокруг иммутабельного map, где в шарпе постелили соломку, а вообще везде.
·>И там и там надо вводить два типа. Ведь T и const T это тоже разные типы.

Да.
Но описание типа программистом — одно.


V>>Собсно, только об этом и говорится в обсуждении (многократно по кругу) — что практически любой мутабельный тип можно использовать в т.ч. в иммутабельных сценариях.
·>"Практически" в том смысле если для типа правильно спроектирован const подтип. Ровно та же петрушка, что и с интерфейсом.

Разумеется.
Например, в шарпе интерфейс IEnumerator имеет read-only св-во Current.

Т.е., итераторы на интерфейсах сделаны не только потому что невозможно было накрутить логику как в плюсах через begin/end (в нынешнем шарпе уже можно сделать достаточно близко к плюсовомоу подходу, получив дешевизну), но еще потому что ДРУГОЙ интерфейс обеспечивает ДРУГУЮ семантику. В данном случае IEnumerator — это read-only семантика, т.е. употребима к мутабельным и немутабельным типам. В итоге для каждой коллекции приходится описывать еще и енумератор.

А вот если речь должна идти про сами типы-коллекции, то появляются пары Span/ReadOnlySpan, Memory/ReadOnlyMemory и т.д.

И это еще в шарпе по-лёгкoму, т.к. язык позволяет определять операторы преобразования, поэтому смогли определить неявное конструирование ReadOnly-версий из мутабельных.
В джаве пришлось бы делать двойную работу, окучивая каждую пару.


V>>Остальные сценарии, когда мутабельный объект подаётся по константной ссылке — это просто удобные гарантии, т.к. после вызова метода с таким аргументом ты можешь в коде рассуждать о том, что целевой объект в результате вызова некоей ф-ии с им-аргументом, не изменился.
·>Аналог final.

Не, final-метод в джаве обозначает другое.
Тут аналог readonly-метода в шарпе, но там оно допустимо только для методов структур.
Для GC-классов нет такой возможности.

Но в случае структур, да, шарп уже позволяет повторять семантику C++.


·>Суть моего тезиса в том, что семантика const в других ЯП выражается тоже, просто через другие механизмы языка.