Ну вот тут не соглашусь, пакетная организация кода чего только стоит в D, а так же не нужно разделять на .cpp и .h исходники. Да и вообще С++ слишком переусложнен. Вот пример кода с хабра:
int& (*fpi)(int*) = [](auto* a) -> auto& { return *a; }; // OK
Все понятно?

не весь, шаблоны нельзя пока. Уолтер по этому поводу думает, но дело непростое.

Я не пойму, ты сейчас серьёзно пишешь или иронизируешь?

совершенно серьёзно. и, в общем-то, по фактам: оно примерно так и было. одна из мегафич D — действительно удобные шаблоны, которые не выглядят белибердой, которые удобно использовать, которые можно не только писать, но и читать без труда. также Александреску ответственен за довольно большую часть std.algorithm (и не только).

а начиналось у него всё с того, что: «я попробую, вдруг интересное что?» мне сейчас лень статью об этом искать, но по-моему, она где-то в доббсе была.

не то, чтобы «ушёл с концами»: C++ он не бросил, пишет статьи, выступает на конференциях. но в то же время он весьма активный разработчик на D, написал практически весь костяк std.algorithm (это такой дальний родственник алгоритмов из STL, только использует ranges) и ещё много всякой шаблонной магии в D.

книгу, опять же, написал: «The D Programming Language» (TDPL). как и полагается — отличная книга. её даже перевели на русский, и не так уж плохо, скорее даже хорошо.

Хорошо, что ушел. Плохо, что не бросил C++.

"Не читайте Александреску." (C) А. Степанов.

как минимум потому, что alias this допускается только одно. то есть, никакая это не альтернатива, а именно чемодан без ручки.

если уж так надо — есть интерфейсы, их можно присобачивать к классу много. а лучше вообще писать на шаблонах, которые тупо проверяют наличие нужных методов, и тогда совершенно пофиг на типы и наследования: нужные методы есть? ок, поехали. ranges, например.

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

А интерфейсы (хоть формальные, хоть проверки через is и тому подобное) - это хорошо, но тогда надо для всего подряд ляпать прокси, если у тебя данный интерфейс реализуется отдельным готовым объектом, от которого ты не хочешь наследоваться. Как примитивный пример - допустим, есть объект и ты хочешь иметь возможность его лочить снаружи. Одно дело - когда ты создал внутри мьютекс, написал alias myMutex this и всё. Другое - когда тебе lock|unlock надо явным образом пробрасывать. Шаблонам оно ортогонально.

и давно. и всем пофигу.

алсо, template mixins. на кой тебе этот alias? спокойно делаешь mixin template и миксинишь его в класс/структуру. с методами lock и unlock. потому что высовывать детали реализации (mutex) наружу — моветон. а для универсальной лочки — опять же шаблон, который проверит наличие нужного метода.

хватит уже крестами мыслить, D — не кресты.

С таким успехом и ассемблер - примитивный аналог Си. :)
Разработчикам не нужны "аналоги", "копии", "обходные пути" - им нужен ПРЯМОЙ инструмент для выражения своих мыслей. Ну и надёжный, конечно - что Ди и сделал как замена таймбомбовому Цэ-пи-пи.

Линуксу давно уже нужен нормальный язык, позволяющий хотя бы в 21 веке забыть кошмарный сон "buffer overflow" (а количество этих потенциальных уязвимостей растёт десятикратно с каждой новой перделкой/библиотекой, потому что пишется всё головотяпами-энтузиастами).

Такого человечество не придумало.
Включая язык, секретаршу и энцефалографию.

конечно, буст тоже нечто подобное умеет на шаблонной магии, но попробуйте почитать код буста для этого, а потом — код std.regex.

Этот ваш Дэ задумывался как c++ done right, но в итоге смачно лососнул у c++. О чем говорит текущая его популярность, а вернее его отсутствие. Видать не совсем уж и done right

для винды: -m64 поддерживает m$vc. -m32 поддерживает dmc. -m32mscoff поддерживает m$vc.

для пигвинуса: gcc 4.

точно так же, как и просто extern (C++).