Создание D foundation, организации, которая будет заниматься развитием языка

Я думаю, что тебе стоит просто самому протестировать его.

Мне лень, тем болеее я могу упустить какие-то моменты. Я бы взялся протестировать java+undertow ибо понимаю, что к чему, не первый год в этой теме.

Так что авторы этого фреймворка упускают, либо стыдно сравниться с С++/Java.

Лично меня от D отталкивает только отсутствие хорошей IDE.

Ну так напишите Александреску, пусть на D запилит хорошую IDE для D, покажет всяким эклипсам с идеями. Всего-то надо анализ кода для интеллектуального автодополнения, да рефакторинг с дебагом, больше то наворотов и не надо на первое время.

Тот же Go, не привнеся ничего нового - вон как развернулся

Он нашел неожиданно новую нишу, где ниосиляторы си и кому надо перформанс, но с простым синтаксисом, от надоевшей уже скриптоты в лице питона и руби.

Qt, вон, уже пасть разинула на мобилы!

А что плохого в Qt?

Всего-то надо анализ кода для интеллектуального автодополнения, да рефакторинг с дебагом

Уровнь плагинов к существующим IDE вас не устраивает? Я сам не проверял (пользуюсь разжиревшим Vim), но троюродный полузнакомый знакомого соседа утверждает, что все пристойно. Не мегасупервау, но «пойдет». Речь о плагинах для VisualD, MonoDevelop и Eclipse.

Я сам не проверял (пользуюсь разжиревшим Vim)

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

историй успеха как-то что-то совсем уж :(

У меня их тоже нет. Мой основной интерес в D - это веб, vibe.d и около того, но ничего слишком серьезного, что стоило бы упоминания.

Мой основной интерес в D - это веб, vibe.d и около того

Ну хотя бы в этой нише почему вам хочется работать с D? Какие у него преимущества по сравнению с альтернативами (хотя бы с теми, про которые вы более-менее в курсе)?

Да ладно, половина разбежится только от вида подобного кода: ...

Как-то странно ты код изувечил при копипасте. Не нравится лору #inline)

Таки все разбегутся? Не уж то моя очередь обзываться неосиляторами? ) Не, это глупо и бесполезно для разговора. Хз, лично мне после прочтения документации все было понятно. Особенно если регэкспами пользовался хоть раз.

Может конкретно этот код не супер удачный, там вон даже хак с e! остался.

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

И это даже не аналог «шаблона на шаблоне».

Для такого, когда сложная логика, я имел ввиду не декларативные макросы, а процедурные.

Я где-то уже писал. D в вебе привлекает производительностью. Ruby, Python, JS, PHP - скриптовые языки, все они медленны по сравнению с нативными. JS - для скриптового очень быстр, но даже в самых оптимистичных бенчмарках он в некоторых случаях «всего лишь» в 2 раза медленнее Си. У остальных еще хуже, Ruby, Python - медленные языки. Попытки использовать нативные языки в вебе предпринимаются регулярно, есть у нас и CppCMS, и KORE.io и Silicon, и прочие. Но vibe.d мне кажется наиболее удачной попыткой. Кроме native performance у него еще удачная модель IO, асинхронность под капотом, но без callback hell как в node.

+ веб скрашивает некоторые объективные проблемы языка (например, нет необходимости в GUI).

+ нормальное количество «батареек» для веба,

+ приятный синтаксис,

+ множество разных мелочей в самом языке.

Мне кажется, vibe.d - это довольно привлекательный вариант например для python-разработчика, которому стало не хватать скорости. Вообще, как ни странно, чаще встречаюсь с одобрением D со стороны питонистов, чем C++ников.

Как и следовало ожидать, в лучшем случае ваши претензии объясняются вкусовщиной.

Ну а как оно еще может объясняться? Личным опытом, известным опытом других специалистов и вкусовщиной, само собой. Это же не математика, в таких вещах неоспоримое доказательство не выведешь.

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

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

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

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

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

То есть ты предлагаешь не пытаться делать новые языки, потому что это не всегда удается, а только вносить обратно совместимые изменения в уже популярные? Есть же черта, после которой имеет смысл выкидывать устаревший хлам. Я не хочу жить в мире, где для масштабной системщины вечно будет только от года к году разбухающий C++))

Просто нужен существенный для масс повод для перехода на новую технологию. Ди вот, судя по всему, пока до людей не донес таковой. Третий питон, например, тоже маловато предложил.

Ржавчина лично для меня предлагает достаточно, что бы тратить на нее свое время. Хватит ли другим людям - посмотрим.

Боже, какая мерзость! Не то чтобы я плохо относился к Расту, но синтаксис бесчеловечен.

Анониму чуть выше уже отписался. Вообще, нечего лишний раз макросами пользоваться)

Или тебя и без макросов синтаксис пугает?

И это еще ничего, в вашем коде даже нет ни одного ::

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

рекламирует
очередной восторженный неофит

Что ж так скромно, можно больше снобизма.

рабочие и работающие инструменты таковы, какими их сделала практика использования
люди пытаются сделать что-то идеальное (или идеализированное)

Стоит ли напоминать, что «практично используемым» языком был Си, а С++, к которым вы так тепло относитесь, был именно попыткой сделать «идеальный Си»?

На самом деле это было брюзжание :) У растового синтаксиса есть неоспоримое достоинство - он целостен.

Рекламного шума вокруг D много, а вот историй успеха как-то что-то совсем уж :(

А зачем? У нас, например, почти все переписано на D (с c/с++/java/fortran). Причем даже ОЧЕНЬ старые системы почти вычищены. Теперь вместо лапши и зоопарка один инструмент. (правда есть еще OCaml, который немного в стороне и менять его не планируем). Проблемы вижу только в отсутствии спецов по языку. Начали брать с++ спецов хороших, которые за месяц без проблем перестраивались на D.

Так что пока кто-то думает взлетит/невзлетит у нас он уже работает и дает реальный профит по сравнению со старым зоопарком.

D в вебе привлекает производительностью.

И? Зачем в вебе производительность? Крупные гиганты, которые реально испытывают проблемы с производительностью веба (Google, FB, Akamai и иже с ними) уже давно имеют собственные решения. Остальным вроде как вполне хватает PHP/Ruby/JS. Ну или Java/C#.

Попытки использовать нативные языки в вебе предпринимаются регулярно, есть у нас и CppCMS, и KORE.io и Silicon, и прочие. Но vibe.d мне кажется наиболее удачной попыткой.

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

Вообще, как ни странно, чаще встречаюсь с одобрением D со стороны питонистов, чем C++ников.

В этом нет ничего странного. D1 вместе с Tango был хорошей альтернативой C++ в 2007-м году. Только этому самому Александреску захотелось D2, вот и пошли на второй круг. За это время вышел не только C++11, но и C++14, да и контуры C++17 уже более-менее определяются. Кроме того, C++ в новых проектах используется там, где языки с GC не сильно-то и нужны, потому там не нужен и D. В старых C++ных проектах D тем более не место. Вот и получается, что C++никам D не нужен.

А питонистов и рубистов понять можно. Им тормоза любимого языка надоели, а в сторону C++ смотреть не модно и не молодежно. Вот и пробуют кто Go, кто Rust, а кто и D. Хотя на C++14 можно писать намного проще и безопаснее, чем на C++98/03, это уже сильно разные языки.

А вы часом не из этих, как их, mediamatics или что-то в этом роде?

Не, это глупо и бесполезно для разговора

Именно.

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

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

Для такого, когда сложная логика, я имел ввиду не декларативные макросы, а процедурные.

Ок, «сложная» логика. Функция, которая сравнивает массив со списком параметров, предварительно взяв абсолютное значение каждого.

#include <array>
#include <iostream>
using namespace std;

template<size_t N, class... Args>
bool eq( array<int, N> a, Args... args ) { 
    return a == array<int, N> { abs( args )... }; 
}

int main() {
    array<int, 3> a { 1, 2, 3 };
    
    cout << eq( a, 1, -2, -3 ) << '\n';
}

Как это будет на rust? Просто ради спортивного интереса.

Что ж так скромно, можно больше снобизма.

Знаете ли, имею право, т.к. в 2005-2007-м был таким же неофитом D, как и вы сейчас. И много защищал его в подобных флеймах на LOR-е и RSDN.

Стоит ли напоминать, что «практично используемым» языком был Си, а С++, к которым вы так тепло относитесь, был именно попыткой сделать «идеальный Си»?

Вы бы, блин, матчасть сначала подучили. Не был C++ никогда попыткой сделать «идеальный Си». Скорее уж это была попытка заставить Simula работать с той же скоростью, что и C.

нет, а кто это? а я из биоинформатики :)

Зачем в вебе производительность?

Исключительно из любви к искусству.

религиозный ужас перед C++ останавливает?

Он самый

D не нужен

Да все уже поняли, что нет бога, кроме c++, и новый стандарт - пророк его. Я всего лишь культурно ем любимый кактус в компании единомышленников, и как будто никого особо не агитирую присоединяться. Пара новостей на лоре - это не агитация.

Ну а как оно еще может объясняться?

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

Вкусовщина же идет лесом, поскольку она может быть применена к чему угодно. Хоть к свободным функциям, хоть к перегруженным операторам, хоть к наследованию, хоть к исключениям.

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

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

Есть же черта, после которой имеет смысл выкидывать устаревший хлам.

Боюсь, что если такая черта и есть, то с ней далеко не так все просто, как хотелось бы.

нет, а кто это? а я из биоинформатики :)

Перепутал, речь шла о https://www.sociomantic.com/ Это контора в которой очень большая кодовая база на D написана и один из работающих там разработчиков всплывал здесь в обсуждении языка D.

В Sociomantic один из самых, имхо, толковых и вменяемых D-шников трудится, Don Clugston. Вроде бы вот одна из лучших презентаций о достоиствах D в реальном мире: http://dconf.org/talks/clugston.html

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

Собственно, это максимум, чего достиг D за последние 16 лет. И, очень похоже, в следующие 16 лет тоже.

мы на dconf тож хотели. Мож на следующий год подготовим что.

Правильно я понимаю, что у вас, в основном вычислительные задачи?

И сколько людей разработкой занимаются, если не секрет?

Как это будет на rust? Просто ради спортивного интереса.

Мимокрокодил: http://is.gd/q251bP

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

http://is.gd/ncSPb3

macro_rules! eq {
    ($a:expr, $($x:expr),*) => {
        $a == [$($x.abs(),)*]
    }
}

fn main() {
    let x = [1, 2, 3];
    println!("{}", eq!(x, 1i32, -2i32, 3i32));
    println!("{}", eq!(x, 1i32, 2i32, 2i32));
}

А так согласен)

Было бы еще здорово убрать суффиксы у литералов, но без контекста не выйдет.

http://is.gd/q251bP

Пару моментов:

а) он сработает и для vec![1, 2, 3], и для vec![1, 2, 3, 4], т.е. с разным кол-вом элементов, и это не аналог моего кода, а аналог:

template<class T, class... Args>
bool eq( T a, Args... args ) { return a == T { abs( args )... }; }

б) [1, 2, 3] и 1i32, -2i32, 3i32 ;)

А так согласен)

И эти люди ругают шаблоны ;) См. замечания выше.

Не только, но есть. Я например вообще не занимаюсь вычислениями. Я отвечаю за взаимодействие .. хм .. компонентов (можно сказать разных отделов, которые занимаются и вычислениями в том числе). Внутренний обмен данными, репликации всякие, синхронизация. Это раньше на яве было. Тут получился профит по утилизации ресурсов и по скорости (XML отправился в утиль). + еще мелкие всякие поделки, типа коллекторов данных со всяких железок. (это было на С/C++). Тут опять же профит в том, что теперь они все - просто компоненты внутренней системы и работают с ней как с родной, вместо горождения костылей.

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

D-шников сейчас 12 человек. Все С++сники или явисты.

PS мля вот пишу сейчас и понимаю, что на русском писать все сложнее...:(

Спасибо!

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

Одна из раздражающих меня в ржавчине вещей - это с какой готовностью в стандартную библиотеку включаются макросы. Ладно еще format!, но vec![] меня печалит. Авось потом язык допилят, что бы для таких простых вещей не нужны были макросы, а vec! объявят устаревшим.

Ок, «сложная» логика.

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

Я вот теперь, кстати, не уверен, что процедурные макросы вообще стандартизировали. Так и сижу на ночных сборках.

а) он сработает и для vec![1, 2, 3], и для vec![1, 2, 3, 4], т.е. с разным кол-вом элементов

В смысле?

let x = [1, 2, 3];
println!("{}", eq!(x, 1i32, 2i32, 3i32, 4i32));

<anon>:11:20: 11:50 error: the trait `core::cmp::PartialEq<[i32; 4]>` is not implemented for the type `[i32; 3]` [E0277]
<anon>:11     println!("{}", eq!(x, 1i32, 2i32, 3i32, 4i32));
                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
note: in expansion of format_args!
<std macros>:2:25: 2:56 note: expansion site
<std macros>:1:1: 2:62 note: in expansion of print!
<std macros>:3:1: 3:54 note: expansion site
<std macros>:1:1: 3:58 note: in expansion of println!
<anon>:11:5: 11:52 note: expansion site
error: aborting due to previous error
playpen: application terminated with error code 101

И откуда ты vec! взял тут?

это не аналог моего кода, а аналог

Там же явное [...] используется в макросе, точно не одно и тоже по факту? Ты точно не придираешься? )

б) [1, 2, 3] и 1i32, -2i32, 3i32 ;)

Повторюсь, контекст нужен, что бы типы вывести. Передай результат куда-нибудь, и можно не писать 'i32'. Это вообще к самому макросу не относится))

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

он сработает и для vec![1, 2, 3], и для vec![1, 2, 3, 4], т.е. с разным кол-вом элементов, и это не аналог моего кода, а аналог:

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

Если в твоем заменить eq( a, 1, -2, 3) на eq(a, 1, -2), все отлично компилируется и выдает 0. Более того, оба твоих варианта функционально идентичны в случае массивов, т.к. инициализация массива требует at most N initializers.

Если в моем заменить eq!(x, 1i32, -2i32, 3i32) на eq!(x, 1i32, -2i32), получим

<anon>:11:24: 4:34 error: the trait `core::cmp::PartialEq<[i32; 2]>` is not implemented for the type `[_; 3]` [E0277]

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

б) [1, 2, 3] и 1i32, -2i32, 3i32 ;)

Последствия большей строгости, для беззнаковых типов abs() не определен.

В смысле?

let x = vec![1, 2, 3];
println!("{}", eq!(x, 1i32, 2i32, 3i32, 4i32));

А я у себя выписал функцию именно под массив и массив именно целых. А еще я могу потом добавить второй eq для vector<float> и т.д. Причем не меняя первую функцию. Но это отдельный разговор.

И откуда ты vec! взял тут?

Именно, ты не предусмотрел - а я взял и использовал. В то время как в моем коде компилятор сразу наругает.

Повторюсь, контекст нужен, что бы типы вывести. Передай результат куда-нибудь, и можно не писать 'i32'. Это вообще к самому макросу не относится))

Я вижу конкретный пример и он крив, остальное - оправдания кривости ;).

Во-первых, там не Vec а честные массивы.

см. выше.

Если в твоем заменить eq( a, 1, -2, 3) на eq(a, 1, -2), все отлично компилируется и выдает 0

Да, неуказанные значения будут равны 0. А вот лишний ты не добавишь. Это как параметры по умолчанию, которых в rust нет. Или они по твоему тоже «ошибка»?

Ну, и если вдруг захочется явно запретить указывать меньше параметров:

template<size_t N, class... Args>
typename enable_if<sizeof...(Args)==N, bool>::type
eq( array<int, N> a, Args... args ) { 

Но это уже на любителя, повторюсь в С++ ожидаемое поведение - позволять указывать не все элементы и использовать дефолтное значение для остальных..

Да, неуказанные значения будут равны 0. А вот лишний ты не добавишь.

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

Вот это уже лучше, я к слову и забыл про enable_if. От него правда страница нечитаемых ошибок получается. Лучше уж так

template<size_t N, class... Args>
eq( array<int, N> a, Args... args ) {
    static_assert(N==sizeof...(args), "Array size mismatch");
    return a == array<int, N> { abs( args )... }; 
}

И почему это - желаемое поведение?

char buf[256] = "Hello!"
vector<int> v( 256 ) { 3, 2, 1 };

Изобрази на rust.

В расте любое несовпадение размеров этих массивов приводит к ошибке компиляции

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

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

Я это поведение _уже_ реализовал легко и просто, а вот ты обратное у себя в rust не сможешь.

А я у себя выписал функцию именно под массив и массив именно целых.

Ээээ, это все особенности реализации, не?

Было ж ТЗ:

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

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

А еще я могу потом добавить второй eq для vector<float> и т.д.

Ржавый вариант с f32 сразу работает.

Именно, ты не предусмотрел - а я взял и использовал. В то время как в моем коде компилятор сразу наругает.

Сравнение Vec и [] разной длинны всегда ложь выдает. Но не ошибка сборки, это да.

Это как параметры по умолчанию, которых в rust нет.

Скорей бы они там определились и впилили уже какой-нибудь вариант этого дела в язык.

Я вижу конкретный пример и он крив, остальное - оправдания кривости ;).

Это к макросу вообще не относится, это особенность языка. И да, строгость - это наоборот достоинство.

От него правда страница нечитаемых ошибок получается

Вылазь из криокамеры:

./test.cpp:14:13: error: no matching function for call to 'eq'
    cout << eq( a, 1, -2 ) << '\n';
            ^~
./test.cpp:6:20: note: candidate template ignored: disabled by 'enable_if' [with
      N = 3, Args = <int, int>]
typename enable_if<sizeof...(Args)==N, bool>::type

Лучше уж так

Вариант с enable_if дает возможность выбрать другую функцию, если она есть. Впрочем если такое не предполагается - то да, static_assert будет проще.

Ээээ, это все особенности реализации, не?

Нет, конечно, я бы тогда мог выкинуть array и просто писать везде T.

А ты теперь хочешь, что бы на ржавчине все нюансы твоей конкретной плюсовой реализации были.

Нет, это тебе лень писать проверку, а мне было не лень - и я явно выписал какой тип ожидаю.

Ржавый вариант с f32 сразу работает.

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

gcc 5.2 выдал

test.cpp: In function 'int main()':
test.cpp:14:21: error: no matching function for call to 'eq(std::array<int, 3ull>&, int)'
     cout << eq( a, 1) << '\n';
                     ^
test.cpp:7:1: note: candidate: template<long long unsigned int N, class ... Args> typename std::enable_if<(sizeof... (Args) == N), bool>::type eq(std::array<int, N>, Args ...)
 eq( array<int, N> a, Args... args ) {
 ^
test.cpp:7:1: note:   template argument deduction/substitution failed:
test.cpp: In substitution of 'template<long long unsigned int N, class ... Args> typename std::enable_if<(sizeof... (Args) == N), bool>::type eq(std::array<int, N>, Args ...) [with long long unsigned int N = 3ull; Args = {int}]':
test.cpp:14:21:   required from here
test.cpp:7:1: error: no type named 'type' in 'struct std::enable_if<false, bool>'

gcc 5.2 выдал

gcc оказался не таким умным, но даже так нет никакой «страницы нечитаемого текста». Возьмем пример ошибки rust (не от меня, чтоб быть объективнее, а выше по топику):

<anon>:11:20: 11:50 error: the trait `core::cmp::PartialEq<[i32; 4]>` is not implemented for the type `[i32; 3]` [E0277]
<anon>:11     println!("{}", eq!(x, 1i32, 2i32, 3i32, 4i32));
                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
note: in expansion of format_args!
<std macros>:2:25: 2:56 note: expansion site
<std macros>:1:1: 2:62 note: in expansion of print!
<std macros>:3:1: 3:54 note: expansion site
<std macros>:1:1: 3:58 note: in expansion of println!

Ты серьезно считаешь, что это лучше и понятней?

И надо заметить, что gcc, выдав немногим больше текста, выдал полезную информацию - точную строчку кода и параметры. А тут «%бись с этой %ней сам».

руст еще маленький, говорит плохо.

Ты серьезно считаешь, что это лучше и понятней?

Ты нет? Он в первой строчке прямо пишет, что не может сравнить два массива из-за разницы в размерах, в чем проблема и состоит. gcc пишет что-то про нехватку функции и отсутствие типа type в struct std::enable_if<false, bool>. Буквальная интерпретация ошибки не говорит вообще ничего о проблеме.

Ты нет? Он в первой строчке прямо пишет, что не может сравнить два массива из-за разницы в размерах

Он не пишет главного - где оно это не может. Тут у тебя простой пример и ты знаешь, что format_args!, println!, print! не причем, а проблема в твоем последнем макросе. А в сложном проекте тебе придется пробежать по всем макросам глазами и научится компилировать код (не особо читаемый к тому же) в голове, чтоб найти в этой массе кода ошибку.

gcc пишет что-то про нехватку функции и отсутствие типа type в struct std::enable_if<false, bool>. Буквальная интерпретация ошибки не говорит вообще ничего о проблеме.

gcc выдал тебе все, чтоб понять где ошибка и почему. Включая текст с тем самым enable_if. rust этого не сделал.

Напомню всем ИТТ, что в расте можно не только жонглировать макросами, но и писать полноценные плагины к компилятору, которые несравнимо мощнее.
https://doc.rust-lang.org/book/compiler-plugins.html

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

gcc и clang умели это еще когда слово rust не вызывало никаких ассоциаций с программированием. Вот только надо это для крайне узкого круга задач. Если вообще надо - проблем с поддержкой и сборкой будет гораздо больше чем пользы.

Он не пишет главного - где оно это не может.

http://is.gd/E26oQw Так же, как и в крестах, указывает вначале на место раскрытия макроса, потом по всей цепочке вложенности. Очевидно, в таких ошибках тебя интересует именно место раскрытия.

gcc выдал тебе все, чтоб понять где ошибка и почему. Включая текст с тем самым enable_if. rust этого не сделал.

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

Очевидно, в таких ошибках тебя интересует именно место раскрытия.

Действительно, а место самой ошибки и откуда какой макрос дергал следующий я догадаюсь сам. Ведь макросы всегда - одна или две примитивные строки. Ну как в этом примере:

~$ cat ./test.cpp
#define M1( a, b ) \
   (a) / (b)

#define M2( a, b ) \
   if( M1( (a), (b) ) ) return 0;

int main() {
   M2( 1, 0 );
}
~$ clang++ ./test.cpp
./test.cpp:8:4: warning: division by zero is undefined [-Wdivision-by-zero]
   M2( 1, 0 );
   ^~~~~~~~~~
./test.cpp:5:8: note: expanded from macro 'M2'
   if( M1( (a), (b) ) ) return 0;
       ^~~~~~~~~~~~~~
./test.cpp:2:8: note: expanded from macro 'M1'
   (a) / (b)
       ^ ~~~
1 warning generated.

Где зачем-то компилятор рассказывает абсолютно ненужную информацию.