The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск компилятора языка D 2.111

06.04.2025 07:29

Опубликован релиз DMD 2.111, эталонного компилятора для языка D. Код компилятора распространяется под свободной лицензией BSL (Boost Software License). Поддерживаются системы Linux, Windows, macOS и FreeBSD.

Язык D использует статическую типизацию, обладает синтаксисом, схожим с C/C++, и обеспечивает производительность компилируемых языков. Язык D также заимствует некоторые возможности динамических языков, полезные для повышения эффективности разработки и обеспечения безопасности. Например, имеется поддержка: ассоциативных массивов, косвенного определения типов, автоматического управления памятью, средств параллельного программирования, шаблонов, компонентов для метапрограммирования. Опционально доступен сборщик мусора. В программах на языке D можно использовать библиотеки на языке C, а также некоторые библиотеки на C++ и Objective-C.

Выпуск включает изменения за более чем полугодовой период, не вошедшие в релиз 2.110, который скорее являлся корректирующим и содержащим только исправления. Среди изменений в выпуске 2.111:

  • Добавлена функция профилирования времени сборки, включаемая через флаг "-ftime-trace" в компиляторе DMD. Компилятор LDC уже обладал этой функцией. Видео с руководством по использовании time-trace.
  • Флаг компилятора "-i" теперь корректно обрабатывает и файлы на языке Си.
  • В шаблонные миксины добавлена возможность использования синтаксиса присваивания:
    
        mixin MyMixinTemplate!(Args) myName; // старый стиль
        mixin myName = MyMixinTemplate!(Args); // новый стиль
    
  • Для методов "extern(Objective-C)" теперь автоматически генерируются селекторы, даже если не указан аттрибут "@selector":
    
       extern(Objective-C) 
       extern class NSObject {
           static NSObject alloc(); // Generates as "alloc"
           NSObject init(); // Generates as "init"
       }
    
       extern(Objective-C)
       class Fox : NSObject {
           bool fluffy;
    
           @property bool isFluffy() => fluffy; // "isFluffy"
           @property void isFluffy(bool value) { fluffy = value; } // "setFluffy:"
    
           void yip(int a) @selector("bark:") { // "bark:"
               // ...
           }
       
           void doSomething(int a, int b, int c) { // "doSomething:b:c:"
               // ...
           }
       }
    
  • Добавлено placement-выражение "new" для инициализации указанным значением (без GC).
    
       struct S
       {
           float d;
           int i;
           char c;
       }
      ... 
       S s;
       S* p = new (s) S(3.14, 42, 'X'); // place new object into s
    
  • Новое ключевое слово "__rvalue", позволяющее реализовать move-семантику. Использовано для добавления библиотечных примитивов "move" и "forward".
  • Добавлен флаг "-preview=safer", при использовании которого все проверки применяемые в коде "@safe" включаются для всего кода, при этом трудно исправимые части (такие как вызов функций "@system") будут всё ещё разрешены в режиме Safer D.
  • Улучшена поддержка классов данных "ref" и "auto ref", которые теперь могут применяться к локальным, глобальных и статическим переменным. Параметры "auto ref" должны определяться только вместе.
  • Включён вывод ошибок для некоторых возможностей, имеющих статус устаревших. Среди них замена "delete" на "destroy", "проваливания" в многозначных "case", самоинициализация переменных.
  • Укороченный синтаксис для определения методов теперь можно использовать и в конструкторах:
    
       struct Number 
       {
           int x;
    
           void vf(int);
           this(int x) => vf(x);
           this(float x) => this(cast(int) x);
       }
    
  • В runtime добавлены Windows-байндинги к BCrypt.
  • В стандартной библиотеке реализован импорт ODBC 4.0 и расширены методы работы с Unicode, версия которого была увеличена до 16.
  • Новый API для "std.sumtype", где появились три функции "has!T", "get!T" и "tryGet!T".
  • В пакетном менеджере dub исправлена ошибка с "cImportPaths".

Дополнительно можно отметить разработку ряда крупных проектов на языке D:

В области разработки игр (GameDev) развиваются несколько движков: HipremeEngine - кросс-платформенный движок, который помимо основных десктопных систем Windows/Linux/macOS поддерживает iOS/Android/Xbox/WebAssembly/PS Vita. Другой проект - Dagon, продолжает развитие 3D-движка с обширными возможностями графики.

В области графических библиотек, помимо OpenGL, развивается поддержку таких библиотек как SDL (включая 3 и 2 версии) и Sokol. Работа с графическими изображениями (decoding/encoding) развивается в пакете gamut, который умеет работать со множеством форматов. Есть поддержка как классических изображений PNG, JPEG и BMP, так и более современных JPEG-XL, QOI и QOIX.

Для построения графических пользовательских интерфейсов (GUI) сформирована новая экосистема библиотек gID, предоставляющая обвязки к многим библиотекам, основанным на GObject, включая полную поддержку GTK 3/4, Arrow/Parquet и Adw. Примеры и список входящих библиотек можно найти в репозитории. Также набирает популярность декларативный фреймворк Fluid, который подходит для применения в играх.

В области веб-разработки на RISC-V архитектуре продемонстрирована работа фреймворка Serverino. Этот минималистичный и производительный веб-фреймворк без других зависимостей может работать на очень слабых машинах, включая некоторые встраиваемые системы с небольшим объёмом памяти.

Продолжается развитие библиотеки для кукольной 2D-анимации в реальном времени - Inochi2D. Среди недавних новшеств проекта были представлены отдельные библиотеки управления памятью и собственный runtime, которые позволяют использовать многие возможности языка без сборщика мусора.

  1. Главная ссылка к новости (https://dlang.org/changelog/2....)
  2. OpenNews: Выпуск компилятора языка D 2.110
  3. OpenNews: Официальный компилятор языка D переведён в разряд свободного ПО
  4. OpenNews: Для языка D представлен runtime для программирования микроконтроллеров
  5. OpenNews: Поддержка языка D включена в состав GCC
  6. OpenNews: В компилятор LDC языка D добавлена поддержка WebAssembly
Автор новости: D_dev
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/63029-dlang
Ключевые слова: dlang
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (45) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 07:46, 06/04/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А где С--?
     
     
  • 2.11, Аноним (11), 08:39, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    С-- уже давно существует
     
     
  • 3.16, Аноним (1), 09:27, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Мана-мана.
    Дык, и я об этом.
     
  • 2.54, Аноним (54), 16:33, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Сдох 20 лет назад.
     

  • 1.2, User (??), 07:47, 06/04/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну, т.е. за всё время так ничего реально используемого и не написали. И не "переписали".
     
  • 1.7, Карлос Сношайтилис (ok), 08:31, 06/04/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Новое ключевое слово "__rvalue", позволяющее реализовать move-семантику
    > Добавлено placement-выражение "new" для инициализации указанным значением (без GC)

    Решили изобрести С++ заново?

     
     
  • 2.9, Аноним (-), 08:33, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Точнее увидев как плох C++ решили сделать заново хороший ООП язык с си подобным синтаксисом. Кого ужасает C++ переходите на D.
     
     
  • 3.10, анон (?), 08:38, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Когда-то заинтересовался D, но тогда у D не было своей GUI библиотеки и похоже нет и поныне так что осталось на уровне интереса.
     
     
  • 4.12, abu (?), 08:49, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В 2015 году уже были упоминания про gtkd и как писать там гуй. Или вы про другое?
     
     
  • 5.20, анонд (?), 09:44, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Это было еще ранее в 2012-13 годах
     
  • 4.18, bdrbt (ok), 09:33, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ну у go и раста тоже с гуём всё плохо - либо биндинги к gtk/qt, либо "на-те-канвас в нём и рисуй", но тем не менее...
     
     
  • 5.21, анонд (?), 09:49, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    У Go есть нативный Fyne, а у Rust есть Slint
    Я не видел библиотек именно на самом D, тем более под Linux, а не Windows
    Использовать биндинги... Ну, проще уж писать на C++ или C в таком случае.
     
     
  • 6.23, n00by (ok), 10:46, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Кажется, автор HTMLayout что-то писал на D в нулевых. Сейчас сходу не нашёл, только биндинги к HTMLayout, так что могу и ошибаться. Но если писал, то показательно, к сожалению для языка.
     
  • 6.25, 12yoexpert (ok), 10:57, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • –3 +/
    у раста есть только биндинги к qt от kdab. не бывает никаких slint, это всё для маленьких детей
     
     
  • 7.33, Прохожий (??), 13:16, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    egui, iced, tauri, slint, dioxus desktop и другие, названия которых уже забыл. И всё перечисленное - это не биндинги к QT.
     
  • 6.29, Hck3r (?), 11:10, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Dlangui из нативного.
    Были еще несколько нативных библиотек, но они до релизных версий как-то не дошли (вроде dtk от Animous)
     
  • 6.32, Аноним (32), 11:30, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +4 +/
    С каких это пор биндинги стали чем-то плохим?! Тушеночная невеста нас всех разоблачила.
     
     
  • 7.58, Александр (??), 18:19, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Я думаю проблема в реализации биндинга и его поддержки.
     
  • 3.14, n00by (ok), 09:09, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Похоже, мастер метапрограммирования Александреску сбежал от экспертов, полагающих Си++ ООП языком.
     
     
  • 4.19, Аноним (1), 09:40, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Далеко убежал?
     
     
  • 5.22, n00by (ok), 10:40, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В поисковик беги. Там найдёшь и С--, и кто такой Александреску.
     
  • 4.26, 12yoexpert (ok), 10:58, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    ну и где он теперь со свими положениями? помню, его выкупил фейсбук и он исчез навсегда

    вроде бы было от него ещё полтора клона бустовых либ на плюсах

     
     
  • 5.30, Hck3r (?), 11:11, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Он в нвидиа сейчас
    Продолжает выступать на конфах вроде тоже
     
  • 4.73, Аноним (73), 01:37, 07/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Дело было так:
    - Андре-ей, у нас тут метапрогра-а-аммы!
    - Уже бегу
     
  • 3.57, Аноним (57), 18:18, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    На что переходить, если ужасает ООП?
     
     
  • 4.59, Аноним (59), 18:21, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > На что переходить, если ужасает ООП?

    На ФП тогда наверное - F# или Ocaml

     
  • 2.31, User (??), 11:26, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Новое ключевое слово "__rvalue", позволяющее реализовать move-семантику
    >> Добавлено placement-выражение "new" для инициализации указанным значением (без GC)
    > Решили изобрести С++ заново?

    Ну, оно, если склероз мне не изменяет, одно время и позиционировалось, как "c++ done right" - но, судя по всему, норот так и не понял, зачем ему ещё одна (пусть даже и лудшая) c++ при наличии первой с её накопленным объемом кода...

     
     
  • 3.36, Аноним (36), 13:36, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Тут как обычно. Сначала сделали то что делать было нельзя категорически - сборщик мусора.

    Когда большинство библиотек стало на это ориентироваться. Стали пропагандировать сборку без сборщика мусора.

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


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

     
     
  • 4.39, Аноним (59), 14:45, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Сборщик мусора это плюс языка.
    Перф когда надо - можно делать, но часто он далеко не везде нужен.
    Пакетный менеджер уже стандарт для почти всех языков - без него выглядит архаично.
     
     
  • 5.64, Аноним (64), 19:23, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >Сборщик мусора это плюс языка.

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

     
     
  • 6.66, Аноним (59), 19:54, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >>Сборщик мусора это плюс языка.
    > Если без него нельзя обойтись - то это минус, жирнющий минус, в
    > некоторых случаях даже "гвоздь в крышку гроба". Нельзя костыль называть плюсом,
    > разве если ты маркетолог.

    Но обойтись без него можно - и конечно же все кто полноценно используют Ди легко это делают там где это нужно

    Другой вопрос - что поскольку уровень программистов на Ди достаточно высокий - они еще и отлично понимают как устроены оптимизации, cache-locality, auto vectorization и прочие техники и где это нужно, а где и нет.

    Но тут конечно только с опытом знания приходят - это не просто направо-налево кричать "если ГЦ - это гвоздь в крышку гроба" - там думать уметь надо ;)

     
     
  • 7.67, Аноним (36), 20:44, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > "если ГЦ - это гвоздь в крышку гроба" - там думать уметь надо ;)

    Вот именно из-за того что думать умет надо - это и есть гвоздь в крышку гроба.

    Ибо большинство до этого этапа не дойдет.

     
     
  • 8.68, Аноним (59), 21:15, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Можно и не думать Код будет работать - просто может быть не очень быстро... текст свёрнут, показать
     
  • 4.48, morphe (?), 15:28, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Сейчас вот у новомодных языков модно новую такую же ошибку совершать, лепить то что точно нельзя делать - СВОЙ пакетный менеджер. А потом пытаться доказать что и без него писать можно.

    А какая альтернатива? Каждому пакету пытаться пробиваться в репозитории debian/rhel/archlinux/...?
    А кто их туда пустит, пока их никто не использует? А кто их будет использовать пока их нельзя нормально поставить?

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

    Делать свой "не-пакетный-менеджер", как golang, и в итоге получить пакетный менеджер, но хуже?

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

     
  • 4.55, User (??), 17:37, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Тут как обычно. Сначала сделали то что делать было нельзя категорически -
    > сборщик мусора.

    Ээээт же ж не "better c", который "системный", а "better cpp", который "аппликушечный" - чем там сборщик мусора-то помешал?

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

    Не, ну можно конечно на "системный" надеяться - тока в двух самых популярных системах, которые генерируют 99% выручки по пользовательскому, как минимум, софту - оного просто нет.

     
     
  • 5.75, Аноним (73), 03:30, 07/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > а "better cpp", который "аппликушечный" - чем там сборщик мусора-то помешал?

    Тем, что C# уже есть?

     
     
  • 6.77, Аноним (59), 09:33, 07/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Runtime to the moon
     
  • 4.62, Александр (??), 18:27, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > лепить то что точно нельзя делать - СВОЙ пакетный менеджер. А потом пытаться доказать что и без него писать можно.

    Не вижу в этом проблемы. Пакетный менеджер должен быть, быть один и позиционироваться как: "must have, но если очень хочется, то и без него, но не стоит". Вообще идеально, если так же дела будут обстоять и с системой сборки. А то сейчас в C++ всё это та ещё дичь: два пакетных менеджера и добрый десяток систем сборки. Влезаешь и не знаешь, как это друг с другом связать. От этого ещё и сами пакетные менеджеры усложнены.

     
  • 3.61, Аноним (57), 18:24, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > одно время и позиционировалось, как "c++ done right"

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

     
     
  • 4.69, User (??), 21:21, 06/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >> одно время и позиционировалось, как "c++ done right"
    > В эту ловушку кто только ни попадал, но даже в случае головокружительного
    > успеха всё равно получалась всего лишь более быстрая лошадь.

    Диалектический переход количества-в-качество еще никто не отменял )))

     
     
  • 5.76, Аноним (76), 08:44, 07/04/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Диалектический переход количества-в-качество еще никто не отменял )))

    Я отменяю.

     

  • 1.13, анон (?), 08:50, 06/04/2025 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +1 +/
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2025 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру