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

Ну если тупо на слайсах, то так:

Не, это вообще не то.

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

Не нравятся именно макросы? Тогда проблемы не вижу.

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

Не, это вообще не то.

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

А чья? У меня много раз появлялось желание оторвать яйца писавшему иксовую часть fglrx, пушо судя по стектрейсу сегфолты зачастую идут именно оттуда.

Тогда согласен - всего бы добавить переменное количество аргументов и всякие там vec! будут не нужны.

В том же С++ для этого добавили std::initializer_list. Т.е. даже не нужно возится с переменным кол-вом аргументов, они у тебя помещаются в один параметр, и можно даже из разделять на группы:

foo( 1, 2, 3 );
foo( { 1, 2, 3 }, { 4, 5, 6 } );

Что с просто «добавить переменное количество аргументов» не выйдет.

Ну так потому что нет переменного количества аргументов.

Нет, это и так было понятно.

Или что конкретно тебя не устраивает?

Не хочется все начинать сначала, пусть будет уже так :)

Таак, ну для ограничения по типам можно тогда трейты задействовать. Вот вариант с проверкой типов и реализациями только для f32 и i32, причем делающими чего-то там разное.

Макрос тут, по сути, просто костыль для реализации (пока) отсутствующих в языке функций с переменным числом параметров.

Заодно и от суффиксов у литералов можно избавиться, wtf_eq дает контекст.

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

trait Wtf: PartialEq {
    fn eq(a: &[Self], b: &[Self]) -> bool;
}

impl Wtf for f32 {
    fn eq(a: &[Self], b: &[Self]) -> bool {
        if a.len() != b.len() {
            return false;
        }
        for i in 0 .. a.len() {
            if (a[i] - (b[i] + 1.0)).abs() > 0.00001 {
                return false;
            }
        }
        true
    }
}

impl Wtf for i32 {
    fn eq(a: &[Self], b: &[Self]) -> bool {
        let c: Vec<_> = b.iter().map(|n| n.abs()).collect();
        c == a
    }
}

macro_rules! wtf_eq {
    ($a:expr, $($x:expr),*) => {
        Wtf::eq(&$a, &[$($x,)*])
    }
}

fn main() {
    let a = [1.0, 2.0, 3.0];
    println!("f32 1: {}", wtf_eq!(a, 0.0, 1.0, 2.0));
    println!("f32 2: {}", wtf_eq!(a, 1.0, 2.0, 3.0));
    let b = [1, 2, 3];
    println!("i32 1: {}", wtf_eq!(b, 1, -2, 3));
    println!("i32 2: {}", wtf_eq!(b, 1, 2, 2));
    let c = [7.0, 7.0];
    println!("bad len 1: {}", wtf_eq!(c, 6.0));
    println!("bad len 2: {}", wtf_eq!(c, 6.0, 6.0, 6.0));
    println!("ok len: {}", wtf_eq!(c, 6.0, 6.0));
}

f32 1: true
f32 2: false
i32 1: true
i32 2: false
bad len 1: false
bad len 2: false
ok len: true

http://is.gd/OvpvAq

А к чему конкретно мы вообще все это пишем, не напомнишь? О.о

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

Хм, а прикольно.

выдав немногим больше текста

Вроде тут уже сказали, но

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!

не считается, это из-за println!.

Т.е. если написать

fn main() {
    let x = [1];
    let f = eq!(x, 1_i32, 2_i32);
    println!("{}", f);
}

то выдаст просто

<anon>:9:13: 9:33 error: the trait `core::cmp::PartialEq<[i32; 2]>` is not implemented for the type `[_; 1]` [E0277]
<anon>:9     let f = eq!(x, 1_i32, 2_i32);
                     ^~~~~~~~~~~~~~~~~~~~

А тут «%бись с этой %ней сам».

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

Если таки надо отладить кишки, то всегда можно раскрыть макросы

$ cat x.rs 
macro_rules! m {
    ($a:expr) => {{
        let n1: i32 = $a;
        let n2: f32 = $a;
    }};
}

fn main() {
    m!(7);   
}

$ rustc x.rs 
x.rs:9:8: 9:9 error: mismatched types:
 expected `f32`,
    found `_`
(expected f32,
    found integral variable) [E0308]
x.rs:9     m!(7);   
              ^
x.rs:1:1: 6:2 note: in expansion of m!
x.rs:9:5: 9:11 note: expansion site
x.rs:9:8: 9:9 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to previous error
$ rustc -Z unstable-options --pretty=expanded x.rs > y.rs
$ cat y.rs 
#![feature(no_std, prelude_import)]
#![no_std]
#[prelude_import]
use std::prelude::v1::*;
#[macro_use]
extern crate std as std;

fn main() { { let n1: i32 = 7; let n2: f32 = 7; }; }

$ rustc y.rs                                             
y.rs:8:46: 8:47 error: mismatched types:
 expected `f32`,
    found `_`
(expected f32,
    found integral variable) [E0308]
y.rs:8 fn main() { { let n1: i32 = 7; let n2: f32 = 7; }; }
                                                    ^
y.rs:8:46: 8:47 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to previous error

Плюсовые шаблоны так, насколько я знаю, развернуть нельзя) Или как-то можно?

затыкают отсутствие необходимых вещей

Тип того. Хотя мне вообще не нравится, что стандартная библиотека подталкивает на каждый чих использовать макросы - тот же try!. Таки макросы нужно использовать только в крайнем случае, не зря они они вызываются с привлекающим внимание и чужеродным "!".

Короче, надеюсь это пройдет с развитием языка.

Таак, ну для ограничения по типам можно тогда трейты задействовать. Вот вариант с проверкой типов и реализациями только для f32 и i32, причем делающими чего-то там разное.

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

А к чему конкретно мы вообще все это пишем, не напомнишь? О.о

Ты сказал, что, если использовать макросы вместо шаблонов - код будет лучше. Или что-то такое. Впрочем уже давно не важно.

Плюсовые шаблоны так, насколько я знаю, развернуть нельзя) Или как-то можно?

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

но нет проверки кол-ва параметров при компиляции

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

макросы не способны сами по себе заменить шаблоны

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

Ты сказал, что, если использовать макросы вместо шаблонов - код будет лучше. Или что-то такое. Впрочем уже давно не важно.

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

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

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

Модулей в С++ до сих пор нет и непонятно
Менеджера пакетов нет

жабозомби так и тянут свои поганые лапищи к нармальному ЯП.

Какой еще живой язык использует заголовочные файлы? Это еще в си, изначально, была так себе идея, а в плюсах так и подавно.

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

полноценные плагины к компилятору

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

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

Очень даже есть разница. Если это часть стандарта языка, то откуда привязка к конкретному компилятору?

Ровно такого же узкого, как и вероятность встретить подобное в каком-нибудь серьезном проекте.

Чего только не встретишь в сурьезных проэктах)

Очень даже есть разница. Если это часть стандарта языка, то откуда привязка к конкретному компилятору?

Во-первых у rust есть только один компилятор, который можно расширить плагином, и это даже прописано в «стандарте». Т.е. твой упор на «это часть стандарта языка» на практике пшик. Это ровно тоже самое, что взять, например, конкретно clang и использовать только его. Получится точно такая же переносимость (в том числе потому что rust пользуется llvm). Во-вторых ты очевидно рассматриваешь их прежде всего как возможность написания макросов, ну так это костыльно. Откуда восторги? Вместо того, чтоб сделать в языке одни нормальные макросы, сделали их два вида - одни убогие с отвратным синтаксисом, а вторые в виде библиотек. Супер просто, теперь можно выбирать между уродствами.

Чего только не встретишь в сурьезных проэктах)

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

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

Это те же функции и классы только с параметризацией по типу.

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

Какой еще живой язык использует заголовочные файлы?

Модули были во время появления си. Так что дело не в возрасте. Заголовочные файлы очень простая идея, и в си смотрится вполне органично. Вот в C++ это вызывает ряд вопросов. Но совместимость с си же. Модули рано или поздно могут появится в C++. Но я бы не назвал это чем-то критическим.

В каком из новых языков нет своего менеджера пакетов?

Ну был бы свой менеджер у плюсов. Под линукс все равно нужно было бы, как и сейчас, делать deb/rpm. Под виндой - писать инсталлятор. Так что бы это упростило? Я понимаю с питоном, у которого своя инфраструктура, всякие там virtualenv и пр. А тут-то нативно все. Зачем мне ещё один менеджер пакетов?

Забавно. В треде про D адепт руста пишет код на русте.

Главное, что адепты D не пишут код на D.

Да ну? Нативный D, тем не менее, менеджер пакетов имеет.

Выпьем.

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

Нативный D, тем не менее, менеджер пакетов имеет.

D имеет настолько мизерную аудиторию, что наличие у них менеджера пакетов ни о чем не говорит.

Так зачем ещё один менеджер пакетов, если есть нативные, от которых уйти все равно нельзя?

Для удобства разработки.

А в чем удобство-то? Ну нужна мне библиотека, заинсталил я её нативным менеджером, в cmake(или ещё где) прописал. Потратил 5-10 минут. Если пакета для моего дистра нет, то мне все равно его делать (для продакшена), вот и сделал. Потратил от получаса до пары часов. Для ленивых вообще checkinstall есть...

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

а что таки у вас на аватарке такое?

Зачем иметь пакетные менеджеры и репозитории в линуксе, когда можно «скочать без платно и без регистрации»?

Может удобство в том, что не всегда linux или другие ОС с пакетным менеджером? А за пакеты согласен, тут спорить не буду, но опять-же, зачем мне ставить в систему кучу сорц зависимостей которые компилируются вместе с проектом?

На аватарке у меня символ Тзинтча.

«Пакеты» применительно к языкам программирования = пакеты с исходным кодом, а не скомпилированные.

Ну так в нативном менеджере есть пакеты и с сырцами.

Ты перепутал шаблоны с генериками.

В том же С++ для этого добавили std::initializer_list.

Ну а в расте есть «слайс» - по сути, тоже размер плюс элементы.

Нет, это и так было понятно.

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

Не хочется все начинать сначала, пусть будет уже так :)

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

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

не нравится, что стандартная библиотека подталкивает на каждый чих использовать макросы - тот же try!

Ну try! сильно облегчает обработку ошибок. Да и куда деваться без исключений? Разве что монады добавлять.

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

Так зачем ещё один менеджер пакетов, если есть нативные, от которых уйти все равно нельзя?

Потому что они абстрагируют от системы?

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

Потому что они абстрагируют от системы?

Они не абстрагируют от системы, они добавляют ещё одну. Проекту на нативных языках, скорее всего, потребуется поддержка нативных менеджеров/инсталляторов.

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

Проекту - понадобится, компонентам проекта (сотням их) - не понадобится. И языково-специфичные менеджеры пакетов - они как раз для компонентов проектов.

Давайте конкретные примеры. Обычно из dev-зависимостей автоматически получают список бинарных зависимостей для софта. Давайте конкретные примеры, а то непонятно.

Если нужна изоляция и независимость, то лучше уж docker.

Давайте конкретные примеры

cargo: http://doc.crates.io/guide.html

Обычно из dev-зависимостей автоматически получают список бинарных зависимостей для софта

Это где так? В RPM и dpkg список бинарных зависимостей прописывают руками или генерируют с помощью ldd или аналогичных скриптов для других языков.

docker.

«Not even the same sport» (ц)

Это где так?

Для deb:

Depends: ${shlibs:Depends}

Или, например для cmake:

set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON)

cargo: http://doc.crates.io/guide.html

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

Depends: ${shlibs:Depends}

Это работает черз ldd, а не список dev-пакетов.

Мне бы хотелось увидеть примеры приносимой пользы. Типа: было вот так-то, а с языковым пакетным менеджером стало так-то

А ты просто подумай, как сделать функциональность cargo для, например, Си.

А ты просто подумай, как сделать функциональность cargo для, например, Си.

Для начала хотелось бы понять, а зачем такая функциональность нужна.

Для начала хотелось бы понять, а зачем такая функциональность нужна.

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

Для начала хотелось бы понять, а зачем такая функциональность нужна.

Функциональность «скачать пакет XXX версии YYY»? Даже и не знаю.

Выходные кончились, я вернулся))

проблем с поддержкой и сборкой будет гораздо больше чем пользы

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

у rust есть только один компилятор, который можно расширить плагином, и это даже прописано в «стандарте»

У ржавчины просто один актуальный компилятор. Можно ссылку на «прописано в «стандарте»»?

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

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

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

Меня вообще пугает идея использовать интерпретатор для языка уровня си.

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

Про синтаксис макросов - выше обсуждали, это индивидуально. Лично я не страдаю.

Супер просто, теперь можно выбирать между уродствами.

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