Вышла первая версия компилятора D, написанная на D

Тем временем актуальным является C++14, который по удобству и скорости разработки нечего и сравнивать с C++98. А на подходе C++17.

развитие С++, это замечательно. НО! любое развитие C++, отягчено проклятием шаблонов. Деться от унаследованного подхода, не получится

Между тем, программирование на шаблонах --- современный мэйнстрим и чем дальше, тем более важным и общепринятым становится.

Поэтому надеятся на РАДИКАЛЬНОЕ повышение скорости разработки и снижение порога вхождения в круг достаточно «продвинутых» C++ разработчиков, совершенно не приходится.

Ты не понял, что я требую всего-навсего практических подтверждений этих заявлений?

Каких подтверждений? Технология на сегодня не достаточно популярна, чтобы приводить легко верифицируемые ссылки. Делать выводы из собственных проектов, это запретить не может.

Что такое «хакеризмы» в этом контексте?

struct A{ x: Box<int> }

или

fn Somewhat <'a>(p: &'a int) -> &'a int {

почему это «хакеризм». пояснения требуются?

когда идеи «гуёв» были примерно такие же, как космический аппарат из ведра - примитив

какие прорывные идеи в гуестроении появились ну хотя-бы за последние дцать лет?

Никто не думал о скинах, анимации, декларативном дизайне, динамическом позиционировании (и какие вообще должны быть лэйауты

я не понимаю твоего утвержедения. Всё это закладывалось в Qt изначально (кроме декларативного описания, разве что).

Назовите хотя бы три киллер-фичи Qt, за которые вы его называете «мощным»?

1. предельно ВЫЛИЗАННАЯ кросс-- платформенная кодовая база (минимум, ТРИ платформы), с соответствующей визуальной интеграцией.

2. самодостаточная иерархия классов (см. пункт 1!)

3. вылизанная концепция ТИПИЗИРОВАННЫХ слот - сигналов. Это сейчас она стала общим местом.

реализация только этих пунктов (с нуля) потребует (см. п.1.), как минимум, столько же человеко - лет, сколько было вбухано на разработку Qt.

И да, а что такого прорывного предоставляет WPF? Расскажите?

Отчасти так и есть. Что еще больше уменьшает нишу для языков вроде C и C++. И делает тезис «главное в совершенстве знать C, а все остальное свистелки и перделки» еще более абсурдным. Уже очень и очень давно можно нормально зарабатывать и расти по карьерной лестнице вплоть до полного прощания с программизмом вообще не написав ни строчки C-шного кода вне школы/ВУЗа.

Я пишу о стандартной практике в любой конторе.

Не нужно обобщать. Есть стартапы (в которых достаточно легко берутся за использование маргинальных технологий и, что важно, про неудачи из-за этого, практически никто не знает), есть исследовательские отделы и экспериментальные разработки в крупных компаниях (пример с написанным на D lint-ом для C++ в Facebook как раз в тему), есть и подпольные проекты.

Никто не будет закладываться на не вполне понятные риски, пока (хотя-бы!) не появятся основания эти риски прикинуть.

С этим полностью согласен.

но ПОЧЕМУ уже в эти годы в Европе было «раскрученное питоновское сообщество»? Только из свойств языка? Или исходя из практического опыта (и соответствующей раскрутке) использования в образовании?

ИМХО, насколько я знаю историю успеха таких языков, как Perl, Python и Ruby, там было уникальное стечение обстоятельств: с одной стороны, языки оказывались удачными с точки зрения набора возможностей, с другой стороны — появились в нужное время и в нужном месте.

Причем путь к успеху у этих языков был гораздо короче, чем у D и измерялся единицами лет, а не полутора десятками (чуть сложнее с этим у Ruby, который в мире стал популярен после 2005-го, но зато в Японии он был весьма востребован задолго до этого). Ничего подобного для D за 16 лет его развития и за 14 лет широкой известности не произошло.

перестаньте воспринимать D именно как ЗАМЕНУ C++, и всё встанет на свои места.

Ok. Тогда поясните, где место D?

Как я вижу, спектр сейчас такой (если не опускаться совсем уже на уровень ассемблера):

• совсем критичные к расходу ресурсов ниши, в которых живет C (ядра ОС, драйвера, встраиваемые системы, жесткое реальное время) + наследие, вроде моды писать VM и часть базовых библиотек для ЯВУ на C для большей кросс-платформенности + аналогичное наследование в области middleware (упомянутое выше ядро древнего PostgreSQL из этой оперы);
• чуть менее критичные к расходу ресурсов ниши, в которых живет C++ (опять же ОС, драйвера, встраиваемые системы, реальное время, околосистемное ПО, GUI, ресурсоемкие вычисления и т.д.) + наследие со времен, когда Java/C# и пр. вещей не было (или же компьютеры были недостаточно мощными, чтобы тянуть сложный софт на тормозных, но безопасных ЯВУ);
• не критичные к расходу ресурсов ниши, в которых, все-таки, от производительности не отмахиваются (разнообразный сервер-сайд, где сейчас рулит Java и куда проникают языки вроде Go и Erlang-а);
• ниши, где на производительность и потребление ресурсов пофиг (front-end для веба, скрипты и пр.).

Куда следует поместить D, при условии, что по качеству инфраструктуры и количеству библиотек он уступает всему, что есть и активно используется?

Не вопрос. Предложите другую.

Тут уже шиза какая-то. То вы говорите, чтобы я не рассматривал D в качестве замены C++, то просите, чтобы назвал вам таковую.

D всегда позиционировался его авторами как альтернатива C++. Но таковой не стал. На данный момент это исторически достоверный факт :)

Каковы причины такой лютой попа боли от D, это что-то личное?

Где вы лютую боль увидели? Ткните конкретное сообщение.

Послушайте, коллеги!

ИМХО, обсуждение ведётся совсем не с того конца. Какое к чёрту tiobe и HR! Какие, к дьяволу, заработки! Это всё имеет смысл обсуждать при достаточном распространении технологии, а не на этапе вялой пенетрации. Не надо рассуждать о D как о полной замене C++ (с преданием последнего забвению). Всё гораздо проще.

Ситуация, как я её вижу, на сегодня такова (и пожалуйста, постоянно держите за скобками нужды открытых проектов, которые как правило, начинаются в одиночку или очень небольшими коллективами!):

из языкового инструментария программиста, на слуху C#, C++, Python, Java, Go, Delphi, Ruby, Erlang --- в таком порядке. Про Хаскел, Лисп/Шему и т.п., давайте не будем: технологии модные, но абсолютно маргинальные.

Из этой «большой восьмёрки», честными компилируемыми языками являются только 2: C++ и Delphi. C# интерпретируемый («управлеямый») принципиально, Go формально компилируемый, но поддержка рантайма такова, что сводит «честность» к минимуму, если не нулю. Само по себе это не страшно, современное железо достаточно мощное (плюс поддержка JIT), чтобы делать на интерпретируемых языках практически любые задачи, да ещё и «безопасно».

Тем не менее, сплошь и рядом от интерпретируемых языков в проекте отказываются (вынужденно --- деваться некуда!) и переходят на «честный» компилятор. Остаётся C++ и Delphi.

Про Delphi особый сказ: верятно, резкий спад популярности имеет под собой достаточно серьёзные основания, кроме чисто коммерческого аспекта.

Остаётся C++. И тут видим чудную картину: с одной стороны, программирование на шаблонах стало настолько общим местом, что без него о развитии как практического, так и теоретического программирования, говорить не приходится. С другой стороны, реализация этой концепции в C++ настолько уродлива и ненадёжна, а порог вхождения в неё настолько высок, что говорить об удобстве и скорости разработки на C++ просто не приходится. Да, можно сделать всё, что угодно (ассемблер не нужен!), но «процесс изготовления» будет идти весьма неспешно.

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

Результат: абсолютное большинство вновь начинаемых задач планируется на C#. В процессе проект частенько несколько раз умирает (борьба с особенностями «управляемой среды»), теряет кросс-платформенность, и т.п.

Проект «одного человека» позволить себе такую роскошь, как правило, не может. Поэтому сообществу СПО (И сообществу хобби — программистов, тем более, что это часто пересекающиеся множества), как воздух необходим честный компилируемый (высокопроизводительный) язык, дающий высокую скорость разработки, защиту от дурака и достаточно полную свободу рук.

D доказал, что этим условиям он удовлетворяет: достаточно посмотреть на его стандартную библиотеку, насколько мало (!) --- мало для такой большой и молодой системы --- там багов, и насколько быстро она была разработана.

Это не значит, что Rust и Go должны быть забыты --- у них другие ниши и цели.

А вот как универсальное решение --- D вполне перспективен и повторюсь, требуется сообществу СПО, как воздух.

Почему именно D? Предложите другую альтернативу. Я таковой, ПОКА, не знаю.

Язык и главное, компиляторы, стали достаточно зрелыми, чтобы начать их активно использовать. Ну так используйте, чёрт побери!

Перестаньте спорить, является ли «D могильщиком C++» --- речь вовсе не об этом. Посмотрите, может ли D (а порог вхождения в него весьма низок, гораздо ниже, чем в C++) быть мотором вашего проекта. И используйте!

Ждать, пока на tiobe у технологии прибавтся проценты --- могут и должны! --- только большие конторы. У малых коллективов такой роскоши нет.

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

Ещё раз: почему именно D? Предложите другую альтернативу (по всей сумме свойств!). Я таковой, ПОКА, не знаю.

аналогичное наследование в области middleware (упомянутое выше ядро древнего PostgreSQL из этой оперы)

Ой, да ладно, пробовали в Postgres использовать цепепе. После мучений со всякими STL и прочими типа «необходимыми» хвалёными возможностями, цепепе был послан на 3 весёлых буковки, клиентский API на C++ был выпилен, а Postgres попёр в гору. Искусные сишники, которые и цепепе обычно прекрасно знают, но пишут то на C, потому что знают, что такое цепепе :-)

Go формально компилируемый, но поддержка рантайма такова, что сводит «честность» к минимуму, если не нулю

Можете этот тезис развернуть? А то ведь откровенным незнанием матчасти попахивает.

Куда следует поместить D, при условии, что по качеству инфраструктуры и количеству библиотек он уступает всему, что есть и активно используется?

см. предыдущий комментарий.

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

На сегодня (пока не наработана серьёзная инфраструктура) --- как крайне востребованное, но пока малоизвестное (или малоиспользуемое из-за недостатка информации и «эффекта утёнка») решение, преимущественно, для малых коллективов.

Повторюсь --- универсальное (на что не претендуют ни Раст ни, тем более, Гоу), решение.

Ой, да ладно, пробовали в Postgres использовать цепепе.

Ссылочку можно?

Откуда такое внимание к Postgres, сами там работаете и сами выбрасывали C++ оттуда?

Кроме того, тема про D. Расскажите, как вы смотрите на использование D в реализации Postgres.

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

Где вы лютую боль увидели? Ткните конкретное сообщение.

Любое Ваше сообщение в этом треде пропитано ей... Кто Вас так обидел? Брайт, Александреску...? Или это просто чувство досады, что физнь потрачена на С++?

как крайне востребованное

Откуда уверенность, что крайне востребованное?

Ну а в качестве альтернативы D, вполне очевидно — хоть C++, хоть Go, хоть Java, хоть C#, хоть Erlang, хоть Haskell. Качество инструментария и инфраструктуры в любом из этих языков намного лучше, чем в D.

Касательно C++: современный C++, если его изучать как C++, а не как ООП над C, осваивается легко и быстро. Даже шаблоны, если ими не злоупотреблять, очень даже полезный инструмент, без которого выгоды от использования C++ сильно снижаются.

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

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

Когда C++ обвиняют, скажем, в отсутствии модулей и использовании заголовочных файлов, нормальные C++ники признают эту проблему. А вот D-шников, которые бы признали, что с транзитивной иммутабельностью не все так хорошо, мне пока не попадалось.

Ссылочку можно?

the problem was that C++ was a moving target, both as to the language... We won't be buying back into that morass - и ведь правильно сказал Tom. Болото этот ваш цепепе :-)

Откуда такое внимание к Postgres, сами там работаете и сами выбрасывали C++ оттуда?

Просто яркий пример огромного проекта, сверх популярного во всём мире, написанного на ANSI C, что доказывает его успешное применение в любых областях, что доказывает, что никакого другого языка с его чудными возможностями и не надо :-)

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

Язык Go транслируется в нативный код. Это никакой не интерпретатор. Ситуация принципиально друга, нежели в случаях с MSIL (.NET/C#) и JVM (Java/Scala).

AFAIK, основные накладные расходы в run-time в Go — это сборщик мусора, а не гороутины.

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

Вот вот, ч.т.д. Без шаблонов цепепе даже тебе не нужен. Поэтому, учитывая их запредельное уродство, сдаётся мне, что цепепе не нужен никому :-)

Тем не менее, сплошь и рядом от интерпретируемых языков в проекте отказываются (вынужденно --- деваться некуда!) и переходят на «честный» компилятор. Остаётся C++ и Delphi.

Ну не только...

Про Delphi особый сказ: верятно, резкий спад популярности имеет под собой достаточно серьёзные основания, кроме чисто коммерческого аспекта.

С ним та же история что с С++, только ресурсов на развитие у него на пару порядков меньше, чем у конкурентов. Плюс еще сильный вендорлок и виндалок.

Остаётся C++. И тут видим чудную картину: с одной стороны, программирование на шаблонах стало настолько общим местом, что без него о развитии как практического, так и теоретического программирования, говорить не приходится. С другой стороны, реализация этой концепции в C++ настолько уродлива и ненадёжна, а порог вхождения в неё настолько высок, что говорить об удобстве и скорости разработки на C++ просто не приходится. Да, можно сделать всё, что угодно (ассемблер не нужен!), но «процесс изготовления» будет идти весьма неспешно.

У C++ огромная кодовая база, много документации, много реализаций, много разработчиков. Будь у брейнфака все это массы программистов писали бы на нем.

Проект «одного человека» позволить себе такую роскошь, как правило, не может. Поэтому сообществу СПО (И сообществу хобби — программистов, тем более, что это часто пересекающиеся множества), как воздух необходим честный компилируемый (высокопроизводительный) язык, дающий высокую скорость разработки, защиту от дурака и достаточно полную свободу рук.

D доказал, что этим условиям он удовлетворяет: достаточно посмотреть на его стандартную библиотеку, насколько мало (!) --- мало для такой большой и молодой системы --- там багов, и насколько быстро она была разработана.

Главная проблема D, как и любого нового языка, в отсутствии развитого тулчейна, малого комньюнити, малая кодовая база.

Откуда уверенность, что крайне востребованное?

Вы невнимательно прочитали комментарий.

Уверенность из того, что решение 1) универсальное и удобное 2) быстрое в освоении и ИСПОЛЬЗОВАНИИ 3) с защитой от дурака.

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

Если это не находка для малых коллективов, то я не знаю...

Про C++14 и старше: что это гораздо более приятный язык, спорить не собираюсь. Конечно, приятный. Но по вышеприведённым критериям, вовсе не прорывной. И гразная шаблонная магия никуда не делась. а это, между прочим, сразу ограничивает проекты, которые может начать разработчик средней квалификации (о начинающем вообще. лучше промолчать).

Главная проблема D, как и любого нового языка, в отсутствии развитого тулчейна, малого комньюнити, малая кодовая база.

Они не появятся, пока не начать использовать D!

так что, лучше бы меньше слов, больше дела :)

ещё раз: я бы (для малых коллективов, СПО, дистростроителей) самым серьёзным образом присмотрелся бы к D.

the problem was that C++ was a moving target, both as to the language... We won't be buying back into that morass - и ведь правильно сказал Tom. Болото этот ваш цепепе :-)

Во-первых, очень интересно в 2015-ом увидеть ссылку на критику C++ времен 2003-го года.

Во-вторых, ваше неумение отличить PostgesSQL от libpg++ в очередной раз подтверждает степень вашей адекватности.

Просто яркий пример огромного проекта, сверх популярного во всём мире, написанного на ANSI C

Ядро Linux-а еще больше, чем PostgreSQL используется во всем мире. И Линус в адрес C++ еще больше гадостей наговорил. Что же вы такие крутые аргументы игнорируете?

что доказывает его успешное применение в любых областях, что доказывает, что никакого другого языка с его чудными возможностями и не надо

Во-первых, из возможности успешного применения C в любых областях не следует нужность такого применения.

Во-вторых, почему же при такой любви к C вы ссылаетесь еще и на Лисп? Неужели что-то на Лиспе делается проще/лучше/быстрее, чем на C?

Есть один принципиальный момент: отношение D-шников к транзитивной иммутабельности.

Я вообще не D-шник и вообще не считаю иммутабельность какой-то киллер-фичей при разработке многопоточного ПО.

Но Вы хотите изменяемости не изменяемого объекта, я Вас правильно понял? Зачем? Не используйте иммутабельные объекты и делов-то.

А вот D-шников, которые бы признали, что с транзитивной иммутабельностью не все так хорошо, мне пока не попадалось.

я склонен тут послушать больших дядь (паче, у Александреску этот вопрос затронут).

Вероятно, люди, зарабатывающие на консультировании (C++) и не по наслышке знающие о соотв., проблемах, ввели жёсткую иммутабельность не от хорошей жизни.

Вероятно, если недовольство будет достаточным, гайки, со временем, приотпустят :)

:)

кстати, про D... у коллеги снесло крышу от следующего безобидного кусочка. Тот долго думал, откуда тут 1C!

class ServClasses { string[string] наборы; string команда_создания_набора; string логправило; string[string] порты ; string[string] логпрефиксы ; string[][string] протоколы ; string правило; string[] активные_категории;

this() { наборы = [ КАТЕГОРИИ.SSH :«NOSHELLERS» ,КАТЕГОРИИ.ALL :«DROPPERS» ,КАТЕГОРИИ.xFTP :«ONLYFTPRS» ];

foreach (тип; [EnumMembers!КАТЕГОРИИ]) { // заполняем для предопределённых (по умолчанию) категорий активные_категории ~= cast(string)тип; }

Они не появятся, пока не начать использовать D!

Проблема яйца и курицы...

Во-первых, очень интересно в 2015-ом увидеть ссылку на критику C++ времен 2003-го года.

А ты думал, что тебе будет представлена ссылка, как команда Postgres отвергает использование цепепе-14 позавчера? :-)

Во-вторых, ваше неумение отличить PostgesSQL от libpg++ в очередной раз подтверждает степень вашей адекватности.

Ага, а в третьих, не libpg++, а libpq++, если уж додельный такой :-) Но это суть дела не меняет. Клиентский C++ API - libpq++ - был частью Postgres, и был выкинут. :-)

Во-первых, из возможности успешного применения C в любых областях не следует нужность такого применения.

Ну тогда вообще ты не прошибаем. Даже ссылки на успешные применения чего-то иного, чем цепепе, для тебя не доказательства. :-) А мир крутиться только вокруг цепепе :-)

Во-вторых, почему же при такой любви к C вы ссылаетесь еще и на Лисп? Неужели что-то на Лиспе делается проще/лучше/быстрее, чем на C?

Да ещё и красивее. :-) А уродливый цепепе вообще рядом не стоял с Лиспом :-)

Но Вы хотите изменяемости не изменяемого объекта, я Вас правильно понял?

Нет. Не правильно.

В C++ я могу делать так:

// Thread-safe logger.
class logger {
public:
  virtual void info(...); // NOTE: not const method.
};

// Notification: new logger must be used.
struct change_logger_notify {
  logger * m_new_logger;
};

void change_loger_handler( const change_logger_notify & notify ) {
  notify.m_new_logger->info(...); // will be compiled.
  notify.m_new_logger = nullptr; // WON'T BE COMPILED
}

Т.е. в C++ я могу иметь иммутабельный change_logger_notify, который содержит ссылку/указатель на мутабельный объект logger. При этом изменить объект change_logger_notify я не могу, компилятор даст мне по рукам. А вот дернуть мутабельный метод объекта logger-а, ссылка на который есть в change_logger_notify — могу.

В языке D, если change_logger_notify константный/иммутабельный, то таким же становится и все, на что ссылается change_logger_notify. Т.е. в change_logger_handler-е нельзя не только изменить объект change_logger_notify, но и дернуть неконстантный метод logger-а.

Такая транзитивная константность мешает в ряде случаев, связанных с распространением информации между несколькими потоками. Когда есть некий константный envelope (никто не может изменить объект сообщения) и ссылка на мутабельный payload внутри envelope.

Вот вот, ч.т.д. Без шаблонов цепепе даже тебе не нужен.

Да, без шаблонов C++ очень многим C++никам, включая меня, был бы не нужен. Как, впрочем, и D без шаблонов не будет нужен большинству D-шников.

Поэтому, учитывая их запредельное уродство, сдаётся мне, что цепепе не нужен никому :-)

Ваши комплексы по поводу C++ давно всем очевидны. Может хватит их публично демонстрировать?

А уродливый цепепе вообще рядом не стоял с Лиспом :-)

Мне кажете, или вы таким образом онанируете?

А ещё в цепепе можно так:

struct Zhopa {
  int size;
};

struct Popa {
  void bulka(int size) const
  {
    z->size = size;
  }
private:
  Zhopa* z;
};

Хвалёная константность в деле :-) Но разные эксперты-пейсатели будут трубить, дескать, «так происходит, потому что в Попе имеется не Жопа, а указатель на неё, поэтому и менять данные в Жопе позволено» :-)

будут трубить, дескать, «так происходит, потому что в Попе имеется не Жопа, а указатель на неё, поэтому и менять данные в Жопе позволено»

Во-первых, да. Поскольку формально дело обстоит именно так. Никто не мешал разработчику объявить Popa::z как const-указатель.

Во-вторых, в C++ const обозначает всего лишь read-only view на объект, что не всегда есть хорошо. Это проблема, исправить которую не сломав совместимость нельзя.

В-третьих, в D, не имевшем груза совместимости, проблему того, что const не более чем read-only view, попытались решить за счет immutable. Но предложили слишком уж кардинальное решение. Из-за чего от константности вообще приходится отказываться.

Мне кажете, или вы таким образом онанируете?

Вот это фантазии с утра по-раньше :-)

Никто не мешал разработчику объявить Popa::z как const-указатель.

Вот в этом рассуждении кроется частое недомыслие цепепешников. Ибо, такой вопрос, отчасти, резонный, если предположить, что Попу и Жопу пишет один и тот же разработчик, или, даже команда. Но чаще бывает так, что Попа - это класс какой-то заокеанской либы, а Жопу пишет цепепешник у себя дома или в офисе под люминисцентными лампами :-) А отчасти же он резонный потому, что не стоит это всё дерьмо моего времени :-)

Во-вторых, в C++ const обозначает всего лишь read-only view на объект, что не всегда есть хорошо. Это проблема, исправить которую не сломав совместимость нельзя.

Как и всегда, цепепе привносит больше проблем, чем выгод. :-)

Жалко, что форматирование попыло, но такое ощущение, что на C++11/14 было бы очень похоже. За исключением EnumMembers!(). Здесь пришлось бы обходиться чуть более многословным кодом.

Вот в этом рассуждении кроется частое недомыслие цепепешников.

Нет. Это все ваши рассуждения всего лишь типичный поток обид типичных неосиляторов.

Такая транзитивная константность мешает в ряде случаев, связанных с распространением информации между несколькими потоками. Когда есть некий константный envelope (никто не может изменить объект сообщения) и ссылка на мутабельный payload внутри envelope.

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

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

Ага. Только что делать в ситуациях, подобных описанной мной? Полностью отказываться от иммутабельности/константности?

Нет. Это все ваши рассуждения всего лишь типичный поток обид типичных неосиляторов.

Ну а что тебе ещё остаётся сказать, кроме как «неосилятор»? :-) Ведь ты и сам понимаешь, что иные «неосиляторы» могут лить помои на цепепе бесконечно, потому что ущербностей там видимо-невидимо :-)

Ведь ты и сам понимаешь, что иные «неосиляторы» могут лить помои на цепепе бесконечно

Ну хоть что-то вы адекватно оценили. Жаль, что взяли неосиляторы в кавычки.

потому что ущербностей там видимо-невидимо

От проблем C++ никто не отмахивается. Проблема в том, что вы лично в качестве замены C++ может предложить только C. Что выглядит заменой только для вас. Но не для C++ников, которые умеют C++ готовить.

Ага. Только что делать в ситуациях, подобных описанной мной? Полностью отказываться от иммутабельности/константности?

Да надо отказаться от иммутабельности. От константности не нужно...

НО! любое развитие C++, отягчено проклятием шаблонов.

Что это за «проклятие шаблонов» такое? Я понимаю, что пинать шаблоны в C++ модно, но что конкретно с ними не так, что это вдруг стало «проклятием»?

От константности не нужно...

Константность в D транзитивна так же, как и иммутабельность.

Вообще, иммутабельность в D — это могла бы быть отличная штука, решающая проблему read-only view. Грубо говоря, в C++ можно отстрелить себе ногу так:

struct sample {
int a, b, c;
};

int child( const sample & s ) {
  int result = ... // some calculation with s.a, s.b, s.c...
  return result;
}

void parent() {
  sample s{ ... };
  auto f = std::async( child, std::cref(s) ); // child thread started.
  s.a = 0; // OOPS!
  f.get();
}

Здесь child имеет read-only view на объект sample, но parent может в любой момент поменять значение child.

В случае с immutable (если бы такое было в C++) этой проблемы бы не было:

int child(immutable sample & s ) {...}
void parent1() {
  sample s{...};
  auto f = std::async( child, std::iref(s) ); // WON'T COMPILE;
  ...
}
void parent2() {
  immutable sample s{...};
  auto f = std::async( child, std::iref(s) );
  s.a = 0; // WON'T COMPILE!
  ...
}

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

Вот, кстати, я не пойму, почему в С++ тут не могли сделать что-то вроде const T & для ссылок на неизменяемый объект (то есть их можно получить только на const T), а T & const - как аналог того, что есть сейчас. Вообще в С++ много спорных моментов, но заменить его просто нечем.

Вообще в С++ много спорных моментов, но заменить его просто нечем.

Для Qt-погроммистов цепепе слаще морковки и незаменим :-) Это его единственная ниша. :-)

Впрочем в С++ можно это реализовать самому, как-то так:

template <typename T>
class immutable {
  const T m_object;
public:
  template <typename ...Args>
  immutable(Args... args) : m_object(args...) {}

  const T *const operator->() const noexcept {
    return &m_object;
  }
  const T & operator*() const noexcept {
    return m_object;
  }
};

А вот это уже неосилятор без кавычек :-)

В D прелесть immutable еще и в том, что время жизни контролируется автоматически. А в C++ с этим те еще пляски с бубном будут. Например:

struct sample { /* some very large data inside */ };
int child(const immutable<sample> & s) { ... }
void parent() {
  std::future<int> f;
  {
    immutable<sample> s{ ... };
    f = std::async( child,
      // Pass by reference because copy is very expensive.
      std::cref(s) );
  } // s is destroyed here.
  ... // OOPS.
  f.get();
}

В D из-за GC с этим все намного проще.

Ну вообще говоря то же самое случится и без той immutable обертки, разве нет (если просто передать const T &)? А уже для решения этой проблемы нужно либо GC, либо лайфтаймы как в Rust, либо использовать shared_ptr.