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)
Ответ на: комментарий от dave

Я от него устал еще на прошлой работе

а на чем пишете на новой работе или так надоело, что бросили разработку из-за c++?

и вообще не понятно, как на нем люди пишут «для себя» ? реально ли получить удовольствие не будучи извращенцем проводя время за исходниками C++ ?

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

На работе сейчас пишу на Scala.

Для себя развлекаюсь на Haskell. Недавно была идея использовать Rust. Написал прототип. К моему большому удивлению оказалось, что код на Haskell, дает ту же скорость, что и Rust (там колоссальное количество кратко-живущих объектов, причем от них сложно уйти). Задумался

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

Так Rust это же не язык общего назначения. Видимо ваша задача не требовала всю его системную «мощь» ;-D

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

реально ли получить удовольствие не будучи извращенцем проводя время за исходниками C++ ?

Гоферы же как-то живут со своим поделием.

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

В Си++, конечно, есть.

Есть возможность и есть необходимость — это ну очень разные вещи.

C++ никого не заставляет писать так:

std::ifstream * f = new std::ifstream("myfile.txt");
if(f->is_open()) {
  ...
  f->close();
  delete f;
}
Так можно написать, но только если вам никто почему-то не показал намного более простой альтернативный вариант:
std::ifstream f("myfile.txt");
if(f.is_open()) {
  ...
}

Ты же не думаешь, что все, пишущие на Си++, так разом перешли на RAII и умные указатели.

Я не понимаю, что значит «перешли». Переход на RAII — это вообще самое начало использование C++ в реальном мире (т.е. период где-то с 1985 по 1990). А умные указатели стали более-менее широко известны где-то после 1995-го. Т.е. уже лет как 20 никуда не нужно переходить.

На Си++ пишут от начинающих школьников и студентов до хардкорных профи. Все они пишут очень по-разному

Тут как бы не очень интересны «все». Вот тов. Vudod приводит в пример локальные массивы из Fortran и FreePascal, которые будучи динамическими, все равно автоматически удаляются при выходе из скоупа. Собственно, интересно, чем это отличается от C++ного:

void f(bla-bla-bla) {
  std::vector<double> local_vec(100500, 0.0d);
  ...
}
Причем доступно это в STL для повседневного использования было где-то с 1994-1995-х (ну ладно, пусть даже будем вести отсчет со стандарта C++98 — 1998). Почти 20 лет назад, и раньше, чем это вошло в Fortran и Pascal.

А ведь еще до появления STL люди уже писали свои классы для работы с матрицами и векторами, упрятывая туда все детали управления памятью (как раз за счет RAII).

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

Меня очень сильно завлекло то, что на Rust можно, не особо утруждая себя, писать монадические выражения, в частности, на основе монады продолжений. Если взять известный пакет futures-rs, то оно самое и есть. Zero-cost abstraction, все дела.

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

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

Тут как бы не очень интересны «все». Вот тов. Vudod приводит в пример локальные массивы из Fortran и FreePascal, которые будучи динамическими, все равно автоматически удаляются при выходе из скоупа. Собственно, интересно, чем это отличается от C++ного:

локальные массивы на стеке, вообще-то.

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

и вообще не понятно, как на нем люди пишут «для себя» ? реально ли получить удовольствие не будучи извращенцем проводя время за исходниками C++ ?

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

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

Сложность применения C++ зачастую оценивают неправильно. Особенно новички, особенно сейчас, когда многие никогда толком на низкоуровневых языках не программировали. С++ пытаются воспринимать как язык типа Java, C# или даже Go: мол, у нас есть прикладная задача, нужно использовать C++, поэтому взяли и погнали. В результате люди пишут простыни кода вроде вот такого:

    static User fromJSON(const rapidjson::Value& doc) {
        if(!doc.IsObject())
            throw std::runtime_error("document should be an object");

        static const char* members[] = { "id", "name", "phone",
                                         "birthday" };
        for(size_t i = 0; i < sizeof(members)/sizeof(members[0]); i++)
            if(!doc.HasMember(members[i]))
                throw std::runtime_error("missing fields");

        uint64_t id = doc["id"].GetUint64();
        std::string name = doc["name"].GetString();
        uint64_t phone = doc["phone"].GetUint64();
        Date birthday = Date::fromJSON(doc["birthday"]);

        User result(id, name, phone, birthday);
        return result;
    }

И это неправильный подход. Имхо, C++ — это язык для создания инструментария, с помощью которого прикладная задача должна решаться намного проще. Например, вместо простыни выше можно было бы написать так:

class User {
public :
  template<typename JSON_IO>
  void json_io(JSON_IO & io) {
    io & json_dto::mandatory("id", _id)
      & json_dto::mandatory("name", _name)
      & json_dto::mandatory("birthday", _birthday)
      & json_dto::mandatory("phone", _phone);
  }
};
Вот еще пример из той же оперы.

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

Уникальность D в свое время была в том, что на начало 2000-х D был единственным языком, который давал C++никам очень похожие возможности, но в нормальной упаковке. На 2007-й год D1 был просто отличным нативным языком с GC, особенно на фоне тогдашней стагнации C++.

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

локальные массивы на стеке, вообще-то.

Все ходы записаны:

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

С локальными массивами на стеке и в C++ все точно так же.

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

Причем доступно это в STL для повседневного использования было где-то с 1994-1995-х (ну ладно, пусть даже будем вести отсчет со стандарта C++98 — 1998). Почти 20 лет назад, и раньше, чем это вошло в Fortran и Pascal.

Для этого нужно знать шаблоны и саму STL

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

Я не хотел обидеть твой любимый Си++. Речь, вообще, шла о Rust

Вообще-то речь в разговоре с тов.Vudod шла об отличиях Fortran/FreePascal/D/OCaml от С++. Куда вы вставили свою очень неточную реплику про Rust, да еще с пояснением «обычно нет необходимости писать явные delete и free»

Отсюда и возник вопрос про обязательность написания явных delete и free в C++.

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

Все ходы записаны:

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

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

Для этого нужно знать шаблоны и саму STL

А что, в Java и C# не нужно знать generic-и и контейнеры из стандартной библиотеки? Или в том же D не нужно знать шаблоны и содержимое std.algorithm, std.range и std.container.*. Хотя бы на уровне того, что там в принципе есть?

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

Тов.Vudod явно писал о том, что ему было ценно именно удаление при выходе:

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

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

Так Rust это же не язык общего назначения.

Интересная точка зрения. Думаю, что большинство Rust-оманов и им сочувствующих с вами не согласятся. Почему вы так думаете? Что мешает Rust-у быть языком общего назначения?

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

А что, в Java и C# не нужно знать generic-и и контейнеры из стандартной библиотеки? Или в том же D не нужно знать шаблоны и содержимое std.algorithm, std.range и std.container.*. Хотя бы на уровне того, что там в принципе есть?

А в Паскале, Фортране, Матлабе не нужно.

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

А в Паскале, Фортране, Матлабе не нужно.

Прекрасно. Зачем тогда людям D и OCaml?

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

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

ckotinko ☆☆☆
()
Ответ на: комментарий от eao197

там не то что «взяли и погнали», а прямо «девяносто, мужики». херачат не приходя в сознание. есть шаблоны? танцуем - шаблоны во все поля. операторы перегружаются? перегружаем всё!

ckotinko ☆☆☆
()
Ответ на: комментарий от eao197

Что мешает Rust-у быть языком общего назначения?

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

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

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

С растом тоже самое. Развитие идёт, релизы стабильно выходят. Но это не значит, что он жив :3

Он еще только рождается. Головка показалась. :-)

В нем нет вещей строго необходимых для системного программирования. Но они в планах.

Для других ниш его годность оценить не могу.

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

Для других ниш его годность оценить не могу.

это сделать просто, дай кому-нибудь «посмотреть» из соседних отделов - готовы ли они на нем писать (это есть у вас не все отделы системной разработкой занимаются ;-D)

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

его позиционирование?

Дык, в том-то и дело, что его позиционирование покрыто мраком. Однозначно понятно, что Rust должен жить там же, где C и C++. Только вот последним в звании языков общего назначения как-то редко отказывают.

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

Не обязательно фронт-энды. А если банк начнет использовать СУБД написанную на Rust-е или брокер для enterprise message bus?

Про фронтэнды можно будет поговорить когда WebAssembly взлетит (если взлетит). И тяжелые приложения, вроде Photoshop-а в Web начнут переезжать.

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

А если банк начнет использовать СУБД написанную на Rust

то он оформит энтерпрайз поддержку, что бы не трогать ее код

так все банки и живут ;-D

А если этой поддержки нету, то ваша база в банк не попадет

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

ну я например на языки без модулей или менеджера зависимостей даже не смотрю ;-D

Очевидно не сталкивались с тем, к чему это приводит.

Именно из-за такой заточки ruby оказался на обочине.

И именно по этой причине, а не какой-либо другой rust может не взлететь.

Я понимаю что такая заточка появляется из-за ориентированности на офтопик, но результата это не меняет.

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

Хуже перла выглядит если честно.

Если честно, программист из тебя - так себе, но экспертное мнение мы выслушали. ;]

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

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

> С растом тоже самое. Развитие идёт, релизы стабильно выходят. Но это не значит, что он жив :3

Он еще только рождается. Головка показалась. :-)


Осталось понять, головка от чего и покажется ли остальная часть. ;]

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

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

Он и сейчас даёт! :) Ничего не изменилось, включая похабный С++ код, который вы привели в качестве первого примера. Хорошо, когда есть template JSON_IO, а когда его нет - идёт именно та лапша. В 21 веке разгребать С++ код - лучше сразу застрелиться и уйти в брэйнфак.

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

Хорошо, когда есть template JSON_IO, а когда его нет - идёт именно та лапша.

Так поинт в том, что _ничего не мешает_ сделать то, что вам нужно. Вместо написания лапши.

В D с этим все в точности тоже самое. D позволяет строить свои велосипеды под конкретную задачу даже лучше, чем C++. Будут ли строить? Или будут писать лапшу?

Я думаю, что ответ очевиден.

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

Ну, cpp тоже не самый идеальный язык, но в D зашли дальше. GC и не GC - это не то, что может переключаться опцией, да, в крестах можно отключить rtti и отвалятся исключения, но не вообще вся библиотека

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

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

Это путь для макаки.

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

Хорошо, когда есть template JSON_IO, а когда его нет - идёт именно та лапша.

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

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

А какая тут нужна магия?

Существует метод класса или не существует известно ещё на этапе компиляции.

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

Если честно, программист из тебя - так себе, но экспертное мнение мы выслушали. ;]

Вот эт новости, критерии оценки покажешь?

Вообще-то backticks - необязательная часть, можешь спокойно юзать обычные кавычки

Да я ничего не говорил про backticks.

Но то, что тебя они пугают хуже Перла

Я не говорил что они пугают.

самому не стыдно?

За то, чего я не говорил и не имел ввиду - нет, не стыдно, лол.

loz ★★★★★
()

В D есть макросы? Там же вроде как даже от препроцессора отказывались. Хотя кому нужны текстовые макросы, когда в common lisp уже давным давно были AST макросы, а в racket они и того по-круче будут. Да сейчас все экспериментальные хаскели, окамлы и всякие там нимы поддерживают AST макросы, а популярные виртуальные машины вместо этого вполне заменяющий макросы рефлекшен.

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

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

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

Я говорил о том, что отделять компайл тайм от рантайма специальными синтаксисом и семантикой, создавая по-сути два языка это провальное занятие, еще со времен макросов C и D ничего нового тут не привносит. А, ну да, открыли AST в 2017, поздравляю.

Теперь сравни синтаксис с тем что я считаю не вырвиглазным адом:

>> repeat i 5 [ do reduce [ to-set-word append copy "my_var_" to-string i i ] ]
== 5
>> my_var_1
== 1
>> my_var_2
== 2
>> my_var_3
== 3
>> my_var_4
== 4
>> my_var_5
== 5
loz ★★★★★
()
Ответ на: комментарий от eao197

Но нет. Нужно подождать D...
А все из-за чего? Из-за того, что...синтаксис с буковками не понравились?

Разве это малая причина? Ну представь ты - с «великим и могучим», а тебе дают клинопись и говорят написать поэму! Ты повесишься, но не напишешь. А и напишешь, сам же потом не прочтёшь. И другие читать не будут. И вот это всё ровно так же относится к С++.

Уолтер - ты сам знаешь, в С++ не новичок. И он далеко не на студенческом раже написал D. И даже объяснил почему. И ты, уверен, эти объяснения тоже читал. Просто ты привык чесать левое ухо правой рукой и принимаешь это «необходимое зло». А теперь представь сувства тех, кто использует для этого левую руку - они искренне не понимают твоего мазохизма; тем более, что D исправляет не только косметическую, но и принципиальную сторону С++. Одни ranges и mixins чего стоят! Плюс вычисления времени компиляции. Уже за одно это можно отодвинуть С++ и внимательнее приглядеться: «а не много ли я трачу усилий на код, который в Ди стократ проще и мощнее?».

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

Да, генерирует и выполняет код вида `my_var_1: 1`.

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

Вот эт новости, критерии оценки покажешь?

Человек, который пугается конкатенации двух строк, какие ещё чувства может вызывать? Или тебя испугало to!string, что даже непрограммисты с английским понимают на раз?

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

Плюс вычисления времени компиляции. Уже за одно это можно отодвинуть С++ и внимательнее приглядеться: «а не много ли я трачу усилий на код, который в Ди стократ проще и мощнее?».

Тут комплексная проблема. У крупных корпораций есть языки для дебилов. У одиночек ценится обилия доступных чужих наработок. Что бы взять готовый движок, обвязать его, может быть чуть-чуть переделать и выкатить для использования. Для людей использующих программирование вместо шахматных задачек C++ или rust подходят намного лучше :-). Так для кого же нужен D,

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

Разве это малая причина?

Конечно. Вот есть некий сферический ученый в вакууме, который начал решать вычислительные задачи лет 15-20 назад. Использовал Fortran, Pascal, MathLab и Matematica, но не всегда ему этого хватало по тем или иным причинам.

Казалось бы, вот есть C++, который отлично под такие задачи подходит. Причем подходит с самого его рождения. Ну помучаешься месяц-два, пока изучать будешь в минимально-необходимом объеме. Зато потом профит. Уж не знаю, как на счет Fortran-а, но уж Pascal точно можно будет выбросить.

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

Но отказываться от этого только из-за синтаксиса. Не понятно.

Уже за одно это можно отодвинуть С++ и внимательнее приглядеться: «а не много ли я трачу усилий на код, который в Ди стократ проще и мощнее?».

Тут есть несколько заковык:

1. Разработчики D насрали на своих пользователей когда через полгода после релиза D 1.000 объявили о начале работ над D2, который будет несовместим с D1. После чего в течении 5-6 лет D2 менялся сильно и регулярно. А развитие D1 и экосистемы вокруг него заглохло.

2. Там, где нужен нейтив без GC, D лично мне не нужен. Т.к. я не хочу терять основные плюшки языка в режиме nogc.

3. Там, где можно жить с GC язык D конкурирует с гораздо лучше развитыми экосистемами Java, Go и .NET.

Отсюда и вопрос о том, есть ли где-то сейчас серьезная ниша для сложного нативного языка с GC.

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

Провальное - только в твоей голове. В реале любая строка, взятая наугад, должна быть понятна программисту. И быть лаконичнее, чем это словоблудие «to-set-word append copy».

static foreach - логичное продолжение синтаксиса после static if (вычисления времени компиляции). Согласен, static несколько заезжено для такой семантики, но видимо, экономили на ключевых словах. :) По мне лучше привыкнуть к static if, чем не иметь этого вообще или иметь в виде ЛИСПовой мешанины.

matumba ★★★★★
()

Да нормальный D язык, а то, что не используют его массово, ну так большинство вообще пишет на PHP/Java/JavaScript и класть хотело на какие-то там системные ЯП, они даже десктопное ПО уже пишут на JavaScript/NodeJS.

Для меня, как активного плюсовика, D вообще хорошо заходит, можно написать то, что ты задумал, но только без костылей C++, необходимости привлечения кучи мелких сторонних библиотек для повседневных задач и создания кросс-платформенных сборочных скриптов на CMAKE. А те же модули в C++ я уже отчаялся ждать.

После C++ научиться программировать на D не проблема, а вот Rust я с наскока осилить не смог и поэтому как-то забил.

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