LINUX.ORG.RU

Rust 1.35

 


1

10

Команда разработчиков Rust рада представить новую версию своего языка: 1.35. Rust - это язык программирования, который позволяет писать надёжные и эффективные программы.

Если у вас уже установлен Rust через rustup,то можно обновиться командой: $ rustup update stable

Главное в обновлении - это реализиция трейтов замыкания Fn, FnOnce, FnMut, для Box<dyn Fn>, Box<dyn FnOnce>, Box<dyn FnMut>, соответственно. Добавление возможности приводить замыкания к указателям на небезопасные функции, вызов макроса dbg!() теперь возможен без аргументов, была проведена стабилизация стандартной библиотеки.

К деталям:

  • В новой версии добавили реализации трейтов Fn, FnOnce, FnMut, для Box<dyn Fn>, Box<dyn FnOnce>, Box<dyn FnMut>, соответственно.
    Теперь такой код будет работать:
    fn foo(x: Box<dyn Fn(u8) -> u8>) -> Vec<u8> {
        vec![1, 2, 3, 4].into_iter().map(x).collect()
    }
    
    Также, можно вызывать замыкание прямо из Box<dyn FnOnce>:
    fn foo(x: Box<dyn FnOnce()>) {
        x()
    }
    

  • Теперь замыкания можно приводить к указателям на unsafe fn.
    Сейчас такой код является валидным:
    /// The safety invariants are those of the `unsafe fn` pointer passed.
    unsafe fn call_unsafe_fn_ptr(f: unsafe fn()) {
        f()
    }
    
    fn main() {
        // SAFETY: There are no invariants.
        // The closure is statically prevented from doing unsafe things.
        unsafe {
            call_unsafe_fn_ptr(|| {
                dbg!();
            });
        }
    }
    

  • Добавлена возможность вызова макроса dbg!() без аргументов.
    Если передать этому макросу какое-то выражение то, макрос выведет его результат. Пример:
    fn main() {
        let mut x = 0;
    
        if dbg!(x == 1) {
            x += 1;
        }
    
        dbg!(x);
    }
    
    При запуске такого кода вы увидите:
    [src/main.rs:4] x == 1 = false
    [src/main.rs:8] x = 0
    
    Сейчас вы можете написать вот так:
    fn main() {
        let condition = true;
    
        if condition {
            dbg!();
        }
    }
    
    При выполнении такого кода вы увидите: [src/main.rs:5]
  • Были стабилизированы некоторые части стандартной библиотеки
    • Новые методы для f32 и f64:
      • f32::copysign
      • f64::copysign
      Собственно, функции копируют знак у другого числа. Пример:
      fn main() {
          assert_eq!(3.5_f32.copysign(-0.42), -3.5);
      }
      
    • Добавлены новые методы для Range типов
      • Range::contains
      • RangeFrom::contains
      • RangeTo::contains
      • RangeInclusive::contains
      • RangeToInclusive::contains
      С этими методами можно легко проверить есть ли определенное значение в последовательности:
      fn main() {
          if (0..=10).contains(&5) {
              println!("Five is included in zero to ten.");
          }
      }
      
    • Полный список стабилизированных API вы можете найти тут
  • В этом обновлении, в Clippy (Это программа, которая проверяет ваш код на наличие многих ошибок) добавили новую проверку для drop_bounds. Это проверка срабатывает, когда вы ставите ограниечение: T: Drop - для обобщенных функции:
    fn foo<T: Drop>(x: T) {}
    
    Иметь ограничение T: Drop чаще всего являеться ошибкой, так как сразу исключаются некоторые типы как, например, u8.(Больше об этом можно читать тут)
  • Очень много улучшено и исправлено в Cargo (пакетный менеджер языка), полный список изменений

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

★★

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

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

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

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

// Ждем с 19-го века

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

где-то я видел предсказание, что программирование станет базовым элементом грамотности

В 1960-е годы Ершов вместе с коллегами начал эксперименты по преподаванию программирования в средней школе, что привело к созданию первой в стране детальной концепции школьной информатики и обогатило нас тезисом «программирование – вторая грамотность».

http://ershov.iis.nsk.su/ru/second_literacy/article

anonymous
()

Ясно

Все и все говно. Assembler с нами.

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

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

Мне кажется это разумным. Появится большое количество предметно-ориентированных языков (а ля 1С) и люди будут пилить в них много чего. Но это не замена настоящего программирования - оно как было так и останется. Работы хватит на всех. Как по мне, так нет смысла привлекать профессионального разработчика если местный доктор сам может написать скрипт для своей системы. А вот если возможностей встроенного языка не хватает, тут уже место для профи. С привлечением профи есть серьезная проблема - разработка ТЗ, без него он ничего не сделает, каким бы профи не был, а это нетривиальная задача.

З.Ы. как не смейся над утверждением что 1С это язык программирования (или среда), но это коммерчески успешная вещь

anonymous
()

Елки-палки...

Писал-писал код в ответ на сообщение, а его удалили... Ну как так? Жалко ведь своих трудов)) В общем было сообщение как в расте с помощью макросов сделать код вида

for (i = 0;i<Т;i++) {
    a+=1;
    for (j = 0;j<T;j++) {
        b+=1;
        for (k = 0;k<T;k++) {
            c+=1;
        }
    }
}
Раста я не знаю, но задачка показалась интересной. И на D я ее решил так:
auto loop(size_t T, Args...)(Args args)
{
    static if (args.length)
    {
        foreach(i; 0..T)
        {
            *args[0] += 1;
            loop!T(args[1..$]);
        }
    }
}

При вызове

size_t a, b;
float c = 0;
double d = 0;

loop!T(&a, &b, &c, &d);

выдаст такой результат

a 20 b 400 c 8000 d 160000

kremator666 посмотри пожалуйста, я правильно понял твою задачу?

Более полный пример тут

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

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

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

В том же самом свифте.

ЭЭЭ. Скобок в примере свифта ровно столько же. Другое дело когда в расте врапперы приходится наворачивать аля RwLock<Arc<Box<...>>>. Вот тут он уже проигрывает практически всем по краткости.

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

В D есть макросы? Их же вроде в своё время обещали не добавлять, что было для меня было решающим фактором не тратить на него время

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

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

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

там не совсем макросы, но то что там есть времени компилции погоже ничуть не хуже

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

Да, вроде всё как я хотел, но я сейчас с телефона, на выгодных подробнее поиграюсь

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

Это отсутствие const generics, что-ли? Никто тайну из этого не делает. И царя модераторы не любят всё-таки не за const generics, надо полагать.

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

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

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

В D есть макросы? Их же вроде в своё время обещали не добавлять

Макросов нет, но шаблоны очень мощные и выразительные, мощнее чем в C++ например. Есть шаблоны не только классов или функций, но вообще произвольных кусков кода, которые можно подмешивать как миксины, плюс как параметры шаблонов можно передавать почти все что угодно включая так называемые алиасы которые просто подставляют что угодно, в общем шаблоны D почти равномочны макросам из других языков. К этому еще добавляется функции времени компиляции (CTFE) и развитая compile time интроспекция. И как вишенка строковые миксины https://tour.dlang.org/tour/en/gems/string-mixins которые позволяют собирать в compile time произвольный код, что почти уже не уступает ast макросам в деле генерации кода.

anonymous
()

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

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

Да, почистили где-то 600 сообщений

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

строковые миксины

Фу таким быть. Никакой гигиены в макросах. В любом языке можно негенерить сорцы и подсунуть на вход компилятору.

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

Фу таким быть. Никакой гигиены в макросах.

Согласен с тем что некрасиво.

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

А это совершенно разные вещи. Тут скорее eval из динамических яыков работающий в compile time. То есть мы не просто генерируем код чем-то внешним, а генерируем его внутри программы и сразу можем скомпилировать и имеем прямой доступ к сгенерированному что все-таки скорее обратное сгенерированным внешним генератором сорцам. Как пример такое https://github.com/PhilippeSigaud/Pegged или https://dlang.org/articles/regular-expression.html внешним генератором кода не сделать.

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

Фу таким быть. Никакой гигиены в макросах. В любом языке можно негенерить сорцы и подсунуть на вход компилятору.

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

Как это все выльется на практике - это жизнь покажет. Сейчас по факту в D макросов нет, но вся их функциональность в языке уже есть.

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

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

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

И именно «некрасивость» кода должна намекать разработчику что такой подход нужно использовать только когда другой возможности нет.

В rust кстати тоже сделали «некрасивые макросы», которые тоже сразу видно и отличаются от основного кода.

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

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

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

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

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

Весь код который проходит через string mixins полностью проверяется в compile time и в случае ошибок просто тупо не соберется.

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

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

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

Конечно АСТ макросы (да и даже простые подстановочные из руста) намного лучше и удобней.

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

полностью проверяется в compile time

Как и шаблоны в плюсах проверяются только конкретные использования макроса. О том, что макрос будет валиден при ЛЮБЫХ входных параметрах можно только молиться. То есть такие макросы неудобно распространять в составе библиотек. Да и вообще сообщения про ошибки компиляции использования таких макросов невозможно понять не вникая в детали реализации самого макроса. В случае с АСТ макросами, ошибки компиляции использования макроса описываются в терминах узера макроса и потому гораздо более информативные.

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

Кстати гигиены в макросах раста нет, что печалит. Да, без гигиены ими проще пользоваться, ибо можно по имени обозначить абслютно любой доступный в лексическом окружении после подстановки идентификатор. Но с другой стороны непонятно как быть с переименованиями, которые может замутить автор кода до вызова макроса. Короче раст не racket, что печально, но всяко лучше строкового препроцессинга из сей. Вот бы можно было сторить АСТ из независимых от контекста ссылок на идентификаторы.

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

Как и шаблоны в плюсах проверяются только конкретные использования макроса.

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

struct Main(Types...)
{
    static foreach(T; Types)
        mixin(T.stringof ~ " _prefix_" ~ T.stringof ~ ";");
        
    auto update()
    {
        static foreach(T; Types)
        	mixin(" _prefix_" ~ T.stringof).update;
    }
}
Этот код создает структуру Main, поля которой определяются передаваемыми типами. Если я передам два типа Foo и Bar, то будут созданы два поля _prefix_Foo и _prefix_Bar (я не стал загромождать код форматированием чтобы делать красивые имена). Если я передам другие типа, будут сгенерированы другие поля. Также при вызове метода Update будут вызваны методы у полей. Настолько удобно, что еще раз повторю - это очень удобно.

И вот здесь вопрос, для чего и каким образом здесь нужна проверка не только конкретного использования макроса? (Подсказка - не нужна от слова совсем)

Так что аргумент притянут за уши.

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

в общем шаблоны D почти равномочны макросам из других языков. К этому еще добавляется функции времени компиляции (CTFE) и развитая compile time интроспекция. И как вишенка строковые миксины https://tour.dlang.org/tour/en/gems/string-mixins которые позволяют собирать в compile time произвольный код, что почти уже не уступает ast макросам в деле генерации кода.

например, PEG парсер Pegged (пример паскаля как DSL в D)

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

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

лисп похожий тоже где-то видел.

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

Тотальные чистки растотем продолжаются

растовые зачистки?

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

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

гигиена будет в реализации defmacro CTFE функциями в D код такого самопального лиспа.

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

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

скорее это похоже на реализацию транслятора лиспа в С++ InteLib от А. В. Столярова Croco. там (в диссере, описывающем транслятор) он писал про «операцию запятая», которая была перекрыта в C++ для некоторых объектов и транслировала S-выражения в С++-выражения из объектов (с перекрытыми конструкторами и операторами) и операций — этакая трансляция «алгебры S-выражений» в «алгебру C++ выражений». реализовано было макросами и шаблонами C++ 98, ЕМНИП. какие-то вещи типа той же гигиены и макросов лиспа были реализованы не полностью и выглядели коряво (например, полного CTFE не получилось ибо С++, в оттранслированном коде частично были рантайм зависимости таких объектов, а в D принципиально возможно от них избавиться если написать достаточно умный компилятор. в современном C++20 и прочая, наверное тоже. только выглядеть это будет как суп из шаблонов шаблонов шаблонов шаблонов ради концептов и constexpr, в этом смысле D гораздо нагляднее). а в целом, вроде бы почти полноценная реализация схемы (в дальнейшем, что-то между схемой и CL) получилась.

один из его студентов, кажется Legioner писал в районе 2008 года реализацию InteLib схемы на D, тогда ещё D v1.0.

я схоронил себе его исходники, которые он выкладывал в lj-шечке. свидетельствую — даже на D v1 получилась годная основа, которую вполне себе можно было развивать и дальше.

сейчас их, конечно же, нужно переписать на актуальный D v2, dub вместо scons, тот же Pegged вместо самопального парсера. и допиливать совместимость в сторону RnRS стандартной схемы.

или реализацию ISLISP запилить, например. то есть, думать в сторону модульных компактных эффективно транслируемых стандартов лиспа.

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

Тут скорее eval из динамических яыков работающий в compile time. То есть мы не просто генерируем код чем-то внешним, а генерируем его внутри программы

.. метакомпилируем в CTFE подмножество целевого языка (D).

реализуя метакомпилятор вроде META II, Ometa или метациклический интерпретатор в духе SICP.

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

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

в том же Dylan D-expressions или PLOT лиспе от David Moon (который изобрёл D-expressions) , частично в goo лиспе (с функциональными объектами) эта проблема частично решена из-за нормальной модульности.

ну то есть, в чём проблема в диалектах в той же racket, например. если в начале диалекта есть #lang MyCoolDialect, и всё это транслируется в нормальный модульный лиспокод.

в D-expressions или в той же OMeta такие «функциональные объекты» можно наследовать, кстати. то есть, модули ещё и ОО.

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

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

возможно. см. тесты того же Pegged. в D есть CTFE трейт «этот код компилируется». то есть, реализация парсера с нужной грамматикой тестируется в CTFE.

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

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

плюс можно контракты написать (а по сути, C++ концепты с нормальным синтаксисом), или прочие инварианты проверить.

например, в книге про D от Александреску много таких примеров.

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

плюс T.typeof и прочие трейты на тайпинфо можно использовать в CTFE в таких sting mixin.

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

парсер C на pegged.

везде enum, static, CTFE. то есть этот AST строится в CTFE, и потенциально может полностью транслироваться через CTFE в D код без лишних рантайм зависимостей.

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

вообще, любопытно было бы сравнить подобные реализации трансляторов лиспа в D и лиспа в раст. в смысле минимизации рантайм зависимостей оттранслированного и бесплатных абстракций времени компиляции (zero-cost abstractions).

D здесь интересен тем, что в CTFE доступен полноценный тайпинфо и трейты на него, то есть, получается наглядный транслятор. но вообще оттранслированный код неявно требует в рантайме D зависимостей от тайпинфо и GC. хотя от GC в D в некоторых случаях можно избавиться, но подмножество такого CTFE языка будет неудобным (замыкания, конструкторы новых объектов и проч.) — переписав рантайм или свою стандартную библиотеку без лишних зависимостей (например, была с реализацией коллекций через массивы, работающая в CTFE).

Раст здесь интересен тем, что потенциально можно обойтись без GC, и получить ещё более компактный рантайм такого лиспа. правда, надо смотреть опять же в примеры типа redox ос на расте, там где собирается более компактный рантайм раста, чем дефолтный.

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

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

насколько я помню, эти «примеры» сводились к тому, что в C++ можно написать auto func(...) {...}, а в расте в таких случаях приходится вводить дополнительный параметр шаблона. Вот редиски модеры, хотят скрыть сей постыдный факт.

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

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

насколько я помню, эти «примеры» сводились к тому, что в C++ можно написать auto func(...) {...}, а в расте в таких случаях приходится вводить дополнительный параметр шаблона. Вот редиски модеры, хотят скрыть сей постыдный факт.

Да в расте нет вывода типа для возвращаемого значения функции, насколько я понимаю это сделано умышленно, ведь в остальном вывод типов там лучше чем в С++, например есть настоящий вывод типа по использованию:

let mut vec = Vec::new(); // здесь тип элемента вектора еще не задан.
let text = "Message";
vec.push(text); // здесь происходит вывод типа.
println!("type_inference_tst: {:?}", vec);
как во взрослых функциональных языках.

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

вообще, любопытно было бы сравнить подобные реализации трансляторов лиспа в D и лиспа в раст. в смысле минимизации рантайм зависимостей оттранслированного и бесплатных абстракций времени компиляции (zero-cost abstractions).

Думаю раст выиграет, все-таки там есть полноценные процедурные (ast) макросы и даже квазицитирование https://github.com/dtolnay/quote.

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

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

XDS Oberon в свое время очень неплохо оптимизировал, особенно перенос всего что возможно в compile time, вполне срамил тогдашние C++ компиляторы.

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