LINUX.ORG.RU

Релиз D 2.076.0

 ,


1

6

Команда разработчиков D с великим удовольствием объявляет о выходе новой стабильной версии DMD: 2.076.0

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

Поддержка static foreach

import std.conv: to;

static foreach(i; 0 .. 10)
{

    // ‘static foreach’ не добавляет вложенной области видимости
    // (так же как и в ‘static if’).
    
    // следующее объявление mixin находится в области видимости модуля
    mixin(`enum x` ~ to!string(i) ~ ` = i;`); // объявляет десять переменных x0, x1, …, x9..., x9
}

import std.range: iota;
// все типы по которым можно итерироваться обычным ‘foreach’
// так же поддерживаются ‘static foreach’
static foreach(i; iota(10))
{
    // используем объявления сгенерированные ранее в 'static foreach'
    pragma(msg, "x", i, ": ", mixin(`x` ~ to!string(i)));
    static assert(mixin(`x` ~ to!string(i)) == i);
}

void main()
{
    import std.conv: text;
    import std.typecons: tuple;
    import std.algorithm: map;
    import std.stdio: writeln;

    // у 'static foreach' есть две формы: объявление и инструкция
    // (так же как у 'static if').
    static foreach(x; iota(3).map!(i => tuple(text("x", i), i)))
    {
        // создает три локальных переменных x0, x1 и x2
        mixin(text(`int `,x[0],` = x[1];`));

        scope(exit) // внутри области видимости 'main'
        {
            writeln(mixin(x[0]));
        }
    }
    
    writeln(x0," ",x1," ",x2); // результат выполнения
}

Улучшения -betterC

Много улучшений было добавлено к новой опции компилятора dmd -betterC, программы скомпилированные с -betterC не будут ссылаться на неиспользуемые части рантайм, asserts реализованы как C <assert.h> вызовы, а phobos (прим. пер. стандартная библиотека) не слинкована по умолчанию.

Хотите знать больше про Better C? Вам сюда.

Добавлена поддержка AVX2

Компилятор теперь может генерировать инструкции AVX2. Поддержка автоматически распознается с помощью -mcpu=native.

Изменения в стандартной библиотеке

std.base64.Base64URLNoPadding позволяет кодирование/декодирование без смещения

import std.base64 : Base64URLNoPadding;

ubyte[] data = [0x83, 0xd7, 0x30, 0x7b, 0xef];
assert(Base64URLNoPadding.encode(data) == "g9cwe-8");
assert(Base64URLNoPadding.decode("g9cwe-8") == data);

std.digest.digest переименовано в std.digest.

std.meta.Stride добавлен, позволяет выбрать подмножество шаблона по размеру шага и отступу

alias attribs = AliasSeq!(short, int, long, ushort, uint, ulong);
static assert(is(Stride!(3, attribs) == AliasSeq!(short, ushort)));
static assert(is(Stride!(3, attribs[1 .. $]) == AliasSeq!(int, uint)));

Был добавлен Config.detached флаг для spawnProcess, он позволяет запускать новые процессы независимо от текущего процесса. Нет нужды ждать их завершения, ведь они никогда не станут зомби процессами! Попытки вызвать std.process.wait или std.process.kill на обособленом процессе бросит исключение.

Теперь можно использовать std.range.chunks с непрямыми диапазонами, но с ограничениями, налагаемыми этими диапазонами.

import std.algorithm.comparison : equal;

int i;

// генератор не сохраняет состояние, так что он не может быть прямым диапазоном
auto inputRange = generate!(() => ++i).take(10);

// мы все еще можем его обработать по частям, но только за один проход
auto chunked = inputRange.chunks(2);

assert(chunked.front.equal([1, 2]));
assert(chunked.front.empty); // итерация по чанку сьедает его
chunked.popFront;
assert(chunked.front.equal([3, 4]));

Теперь std.socket.UnixAddress поддерживает абстрактные адреса. UNIX сокеты обычно идентифицируются по пути. Linux поддерживает непереносимое расширение этой схемы, известное как абстрактный адрес сокета, которое независимо от файловой системы. Начинается абстрактный адрес с нулевого байта.

auto addr = new UnixAddress("\0/tmp/dbus-OtHLWmCLPR");

Добавлена возможность использовать базовый класс когда производится автоматическая реализация интерфейса. Второй шаблон std.typecons.AutoImplement был добавлен, в отличии от существующего он принимает дополнительный параметр. Этот параметр позволяет уточнить класс от которого наследуемся во время автоматической реализация интерфейса.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: CYB3R (всего исправлений: 11)

Ответ на: комментарий от ult

чем именно язык Ада более надежный

намного более строгая типизация, не дающая стрелять по ногам. есть unchecked_conversion, который хоть и даёт стрелять по ногам обойти систему типов, но тем не менее работает только для типов имеющих одинаковый размер. вроде еще есть автоматическая проверка stack overflow, что на мк очень даже полезная фича.

anonymous
()
Ответ на: комментарий от anonymous

в идеале, что-то типа nim/rust/D

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

Ну а те макросы, которые macro_rules, а не «процедурные макросы» как раз как отдельный (уродливый) язык и выглядят.

фичи подмножеств языка райнтайм и компайлтайм в каком-то смысле, «ортогонализированы»: минимум зависимостей от фич подъязыка рантайма в подъязыке - компайлтайма.

Вот не знаю насколько это реально. Сам же приводишь D в пример, где с этим всё плохо. Собственно, к расту ГЦ тоже хотят (хотели?) прикрутить сбоку и есть опасения, что это может вызвать фрагментацию инфраструктуры.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Вот не знаю насколько это реально. Сам же приводишь D в пример, где с этим всё плохо. Собственно, к расту ГЦ тоже хотят (хотели?) прикрутить сбоку и есть опасения, что это может вызвать фрагментацию инфраструктуры.

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

yetanother ★★
()
Ответ на: комментарий от yetanother

Похоже, что ты отвечаешь нe на то, что цитируешь.

Так-то я не имею ничего против возможности оперировать на этапе компиляции теми же средствами языка, как и в рантайме. Просто хотел сказать, что раст (пока?) плохой пример: половина возможностей процедурных макросов ещё имеют статус нестабильных, а остальное стабилизовали скорее вынуждено, чтобы ряд важных библиотек могли работать на релизном расте.

DarkEld3r ★★★★★
()
Последнее исправление: DarkEld3r (всего исправлений: 1)
Ответ на: комментарий от DarkEld3r

Похоже, что ты отвечаешь нe на то, что цитируешь.

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

фичи подмножеств языка райнтайм и компайлтайм в каком-то смысле, «ортогонализированы»: минимум зависимостей от фич подъязыка рантайма в подъязыке - компайлтайма.

Я считаю что не должно быть разделения на подъязык рантайма и подъязык компайлтайма. В Ди сейчас «подъязык компайлтайма» это просто подмножество самого Ди. Если я вызываю функцию и ее значение присваиваю переменной то это рантайм, а если ее значение присваиваю перечислению - компайл-тайм. Все просто без разделения на «подъязыки»:

// Run time
auto foo = my_function(args);
// Compile time
enum bar = my_function(args);
Очень удобно для освоения языка. Ну и прокомментировал фразу что в Ди с этим все плохо - вставил свои пять копеек. Что насчет нестабильных и вынужденно стабильных макросов - нож он же может и для нарезания хлеба использоваться, и человека зарезать можно. С макросами также - можно и хороших дел, и плохих наворотить. Как поймут разработчики Раста что можно стабилизировать, так стабилизируют. Мне кажется это нормальное состояние для развивающегося языка. Другое дело, что макросы в Расте имеют свой особый синтаксис (как я понял) и являются как раз подъязыком компайл-тайма - вот это, как по мне, не комильфо.

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

let x: Vec<u32> = {
    let mut temp_vec = Vec::new();
    temp_vec.push(1);
    temp_vec.push(2);
    temp_vec.push(3);
    temp_vec
};
с помощью следующего макроса:
macro_rules! vec {
    ( $( $x:expr ),* ) => {
        {
            let mut temp_vec = Vec::new();
            $(
                temp_vec.push($x);
            )*
            temp_vec
        }
    };
}
Между этими двумя фрагментами кода существенно большая разница в синтаксисе, человеку нужно учить практически две грамматики. В Ди эти же два фрагмента выглядят следующим образом (не идиоматический код):
// Нешаблонная функция
auto vec1() {
    Array!uint temp_vec;
    
    temp_vec.insertBack(1);
    temp_vec.insertBack(2);
    temp_vec.insertBack(3);
    
    return temp_vec;
}
// Шаблонная функция
auto vec2(Args...)(Args args)
{
    Array!uint temp_vec;
    
    foreach(f; args)
        temp_vec.insertBack(f);
    
    return temp_vec;
}
Полный пример можно проверить тут Разница тоже есть между шаблонной и нешаблонной - но она намного меньше чем в расте - чтобы понять шаблонный вариант нужно знать `foreach` (более чем базовое понятие) и переменное число аргументов (variadic args, тут уже посложнее). Все, остальной код более чем ясен.

Раст в своей нише более чем интересный язык, задумки в его основе реально замечательные и важные. Но какой ценой? Я уверен, что в мире будет только набирать силу тенденция, когда разработка софта из рук профессиональных программистов перейдет в руки специалистов предметной области - т.е. программы для медиков будут писать медики с навыками программирования. В силу того, что проблема коммуникации между медиком(и другими) и программистом реально значительная. И в свете этого тренда, я смотрю на своих коллег, которые пишут на си и плюсах в стиле, как я это называю «код научных сотрудников» и я не представляю, как они перейдут на раст. Их код может быть и гавно с точки зрения профессионала, да что там говорить - он и есть говно. Но он работает, решает поставленную задачу и приносит деньги. И он отлажен(!), да ценой бОльших усилий, чем нужно, на практике, тоже через жопу, но он отлажен, работает и приносит деньги, как я уже сказал. И хрен они перейдут на раст. Нанять профессиональных программистов тоже не всегда вариант. Именно поэтому питон и стрельнул и пользуется популярностью в научных и около кругах. Синтаксис очень важен в этом аспекте.

На этом прерву поток мысле, пора работать. Сорри за стену текста.

yetanother ★★
()
Ответ на: комментарий от yetanother

Очень удобно для освоения языка.

Согласен.

Почитал про макросы Раста тут.

В расте есть ещё другие макросы. Более мощные и больше похожие на «нормальный раст».

В Ди эти же два фрагмента выглядят следующим образом (не идиоматический код):

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

А вот в то, что программистов заменят «специалисты предметной области» не очень верю, но спорить об этом неблагодарное занятие.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

А вот в то, что программистов заменят «специалисты предметной области» не очень верю, но спорить об этом неблагодарное занятие.

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

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

yetanother ★★
()
Ответ на: комментарий от yetanother

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

А буратину из полены только с помощью молотка и пассатижей выстрогать можно?

dzidzitop ★★
()
Ответ на: комментарий от yetanother

можно себе представить то поделие. но пилоты кушают...

dzidzitop ★★
()
Ответ на: комментарий от dzidzitop

А буратину из полены только с помощью молотка и пассатижей выстрогать можно?

Честно говоря не понял мысль. Я имел в виду, что для развивающегося языка незавершенность какой-то «фичи» достаточно нормальное состояние.

можно себе представить то поделие. но пилоты кушают...

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

yetanother ★★
()
Ответ на: комментарий от siropchik

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

Он ничем не выиграет у того же с++. По скорости приложения уступают. Хз..

Теперь приводи обоснования.

hobbit ★★★★★
()
Ответ на: комментарий от yetanother

про буратину - не нужно макросами делать вообще всё что можно.

dzidzitop ★★
()
Ответ на: комментарий от hobbit

А я не стремился никому ничего доказывать. У тебя другое мнение? Ок. Мне все равно, хочешь проверить инфу? Интернет доступен. Любой нормальный человек проверяет инфу в нескольких источниках и далеко не все новости, а точнее их меньшинство дают ссылки на первоисточник.

siropchik
()
Ответ на: комментарий от anonymous

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

ckotinko ☆☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.