Замену C++ делают неправильно

ну пытались получилость D, который еще затейливее

D слишком другой, он сделан скорее с нуля под впечатлением от плюсов. Сборка мусора, достаточно отличий синтаксиса, вот это всё. Я же предлагаю взятьв лоб C++14/17 и, выкинув устаревшую дрянь, слегка подредактировать.

что, например, выкинуть?

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

Ага. И получить c+d? Сборка мусора и прочее не случайно притащили в D, к тому же она там элементарно отключается. Вон в objective-C/Swift тоже не парятся с ручным освобождением памяти - это же ускоряет и упрощает разработку программ. Так что сборка мусора в D скорее плюс, чем минус. У D другой недостаток - это слабое community: тухлые биндинги к Qt, и т.п.

Вон в objective-C/Swift тоже не парятся с ручным освобождением памяти...

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

А что тебе мешает просто не использовать legacy-фичи языка?

Есть такое мнение, что заюзать netfilter руками через ядро намного проще, чем осилить мануал по iptables. Лови параллели.

просто форкнуть нынешний стандарт C++ ? Выпилить оттуда весь груз обратной совместимости, странности и неочевидности, и естественно, добавить улучшательств

Появляются полумертвые D

Сишный препроцессор, сильно урезать инклуды в пользу модулей, множественное наследование, старые enum, голую арифметику указателей без compile-time проверок, deprecate многих C-функций по умолчанию, struct, имеющие методы, C массивы и zero-terminated strings (только возможность конвертить в них значения стандартных классов для вызова C кода), ну и множество мелочей

Мне ничего, кроме тех, кто ими таки обмазывается

можно даже сделать флаг типа --no-legacy-compat

Ну так можно и не делать новый язык. Возьми clang или gcc и напиши плагин, который обрежет С++ до нужного тебе подмножества.

Я же предлагаю

Чего предлагаешь, делай давай. Форкай, пили, пиарь, собирай единомышленников. Предлагателей и так достаточно.

можно даже сделать флаг типа --no-legacy-compat

По-моему, дело идет примерно к этому - к выделению подмножеств языка.

А java в итоге не получится?

начинай пилить, чо уж.

выкинуть [...] множественное наследование [...] struct, имеющие методы

Так, этого до проектирования языков не допускать.

без многих этих штук С++ перестанет быть тем, чем является - гибким универсальным инструментом...

Для C++ сейчас намного полезнее было бы иметь нормальный кроссплатформенный менеджер зависимостей. И нормальный кроссплатформенный билд-тул (более вменяемый, чем CMake).

Замену C++ делают неправильно

так уже сделали правильно, qt называется.

множественное наследование

Чем оно вам всем не угодило? Есть проблемы с ромбовидным наследование - не используй.Имхо, через множественное наследование можно сделать множественную имплементацию интерфейсов(чисто абстрактных классов).

что, например, выкинуть?

Си, все что связанно с си. Си хороший язык, но совместимость с ним портит С++.

Еще один улучшатор выискался. Не надо ничего выпиливать! Само со временем окочурится, как new/delete.

Для C++ сейчас намного полезнее было бы иметь нормальный кроссплатформенный менеджер зависимостей. И нормальный кроссплатформенный билд-тул (более вменяемый, чем CMake).

...и штобы как в Rust %)

я предлагаю начать с более простого выкинуть html и использовать только xhtml

125...

Сишный препроцессор, сильно урезать инклуды в пользу модулей, множественное наследование, старые enum, голую арифметику ...

Вот скажи, что тебе мешает не использовать всё переведенное выше? Зачем именно вырезать из компилятора?

Напиши, как посоветовали, плагин, который «депрекейтит» все «легаси». Например M$ так сделало и очень сильно ругается на весь протухший сишный рантайм.

Система зависимостей для плюсов - фантастика, потому что плюсы - это не жапка, где у тебя стандартная уютненькая vm, куда можно натащить jar-ов и радоваться жизни. На Си/Си++ у тебя множество платформ, систем сборки, тулчейнов, специальных утилит и компиляторов, требуемых при сборке (nvcc, yacc, lex, ...). Тот же opencv собрать по-человечески уже небольшая проблемка.

Да, к той же мысли прихожу.

Угу. С MOC'ом который накладывает кучу ограничений на шаблоны и макросы. При всём том хорошем, что даёт Qt, замена из него никакая.

Ага, и без неё элементарно не работает стандартная библиотека D. И кому он такой нужен? Это как теоретизировать о том, что в плюсы можно притащить GC. Да, можно, но нет больных ублюдков, которые станут это делать.

GC даже для C есть: https://github.com/orangeduck/Cello

И, заметь, очень популярен. А зачем тебе работа со стандартной библиотекой с отключенным GC? GC имеет смысл отключать лишь на некоторых участках программы, и то, думаю, это такая редкость - просто ппц. Смысл в том, что разработка на си/си++ не только сложна, но и очень долга по времени. Людям нужна скорость разработки на уровне python/JavaScript, поэтому всякие Swift и выстреливают, думаю здесь даже не только язык важен, но и вливание в него бабок, приглашение на полную ставку крутых разрабов и т.п.

Обезьянки не осиливают XML, не получится.

qbs

Повторю выше сказанное:

1) Никто не заставляет это использовать.

2) К clang можно прикрутить плагин.

Буду краток: мне концептуально нравится язык D, нравится что есть привязка к Qt5.

Но я очень огорчен уровнем поддержки этого языка в различных IDE и вообще уровнем адаптации в реальных проектах.

Всё еще надеюсь увидеть что именно D будет постепенно завоевывать популярность, а не всякие убогие свефты/шрасты/гоги...

...и штобы как в Rust %)

Ну, например. :)

И, заметь, очень популярен

Где же он популярен, среди кого? А вообще забавно интересно, даже классы влепили туда - всё как хотел ТС.

Я считаю современный язык должен компилироваться в натив, JVM/CLI, JavaScript, LLVM-байткод... Очень неправильно что для покрытия этих платформ разные языки, будто не 21-й век.

Вообще этот Cello можно сравнить с Qt/MOC или Vala по принципу работы? Вот оно - всё для радости автора темы - расширяй языки но не заморачивайся с компиляторами и поддержкой архитектур.

Я вот сейчас не понял: вы решили меня просветить на счет той жопы с управлением зависимостями, которая есть сейчас в C++? Или объясняете причины этой жопы? Или пытаетесь сказать, что решение такой задачи в принципе не возможно?

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

Т.е. в рамках своего проекта можно решать проблемы зависимостей, например, через возможности VCS (git submodule, hg subrepos, svn:externals) и привычной для себя системы сборки. А вот поделиться с кем-нибудь результатами своей работы так, чтобы любой пользователь подключил твои исходники к себе буквально одним щелчком... Вот это уже аттракцион.

Впрочем, подвижки есть. biicode умер, но его авторы сейчас conan делают. Еще недавно на reddit-е ссылка на какой-то менеджер зависимостей новый проскакивала. Вроде как даже какие-то альтернативы CMake (вроде premake5) развиваются.

qbs

А он без Qt живет?

В смысле? Оно использует Qt либы, что логично, но собирать им можно что угодно. Там нет завязки на Qt, как у qmake, и на, C++ как у cmake.

Дока скудная, примеров мало, вот это проблема.

И это хорошо.

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

собственно, D — это попытка сделать, о чём вы говорите

Замену C++ делают неправильно

а что, разве С++ сам по себе это что-то правильное? :)))

Я же предлагаю взятьв лоб C++14/17

неплохо так предлагаете. откуда взять C++14/17 в 2006 году? (примерное появление D)

Сборка мусора

опциональная. кстати, опциональный gc нужен и плюсам

достаточно отличий синтаксиса,

мизерные, хотя и часто спорные нововведения

выкинув устаревшую дрянь, слегка подредактировать.

и как это сделать без «достаточно отличий синтаксиса»? например, устаревшая дрянь это дефайны. но чем их заменить?

а что, разве С++ сам по себе это что-то правильное? :)))

Ну раз gcc перевели на него, так как минимум необходимое.

к тому же она там элементарно отключается

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

опциональная

«Don't want GC? No problem! You can use D with RAII or manual management style as well!» Though true, that's next to useless because there's little support in the standard library for alternative memory management styles (с)

например, устаревшая дрянь это дефайны. но чем их заменить?

Макросами, хотя бы такими как в Rust.

сильно урезать инклуды в пользу модулей

Вот добавят модули, можно будет просто пользоваться ими и не страдать запретительством.