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 (пакетный менеджер языка), полный список изменений

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

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

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

Когда вы все-таки вырастите из мамкиных штанов. Раст победит C/C++/D/Go/нужное подставить - это выражение из ряда пассатижи погубят плоскогубцы. Языки это лишь инструмент, многое еще от других вещей зависит.

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

Раст победит C/C++/D/Go/нужное подставить - это выражение из ряда пассатижи погубят плоскогубцы.

То есть сравнивать между собой электродрели (а скорее наборы столярного инструмента, это будет более правильная аналогия для языков программирования) нельзя?

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

Да кому нужны нечитаемые и функционально ограниченные macro_rules!, когда есть процедурные макросы.

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

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

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

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

Да кому нужны нечитаемые и функционально ограниченные macro_rules!, когда есть процедурные макросы.

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

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

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

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

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

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

Не понял коммента. У компилятора есть несколько стадий. На одной из них происходит резолвинг идентификаторов. Вот я и предлагаю всунуть узерский макро-плагин уже после этого этапа. Ну да, придется вводить апи, позволяющее узерскому макрогенератору резолвить идентификаторы через ядро компилятора, ну чтоб там всякие gen_fresh_iden(«Foo») генерили идентификаторы аля Foo$tratata ну и с текущими поключенными крейтами можно было общатся в духе crate(«log»).resolve(«LogLevel::Info»). Ну не знаю, может это уже слишком поздний этап компиляции и макросу придется генерить AST сильно не похожий на узерский раст. Тогда грусть беда, переписывать весь компилятор придется. Ну или самому парсить весь проект и свой резолвер катать, чтоб макрос мог спросить у либы какие идентификаторы свободны и что именно имел ввиду юзер говоря Result<()> в типе

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

То есть сравнивать между собой электродрели (а скорее наборы столярного инструмента, это будет более правильная аналогия для языков программирования) нельзя?

Ты можешь сказать что для моих задач удобнее вот этот набор инструментов. Другой для этого же набора задач предпочтет другой набор инструментов. Вот так это в жизни происходит. Утверждать же что набор инструментов А победит другие наборы инструментов B, C и D - ну это же очевидная глупость юношеского максимализма на уровне я вчера узнал что есть швейцарский нож и теперь все буду делать только с его помощью так как я крут, мой нож крут и это все стильно и молодежно. Инженеру не следует вестись на хайп.

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

Утверждать же что набор инструментов А победит другие наборы инструментов

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

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

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

Читать учись, не важно о каком DSL идет речь. Инструмент не может никак победить другой инструмент. Это неверная формулировка, если не сказать больше. Инженер скажет что инструмент лучше подходит, но никогда не скажет - «победит». Ты еще скажи, что твой папка сильнее моего и он как мне даст, что ух!

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

Да Инженеры только на Старшой Эдде общаются.

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

Предъявите красный диплом по специальности «Инженероведение».

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

Предъявите красный диплом по специальности «Инженероведение».

А ты поумнее будешь, чем тот анон))

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

Программирование сильно от прочих технологических процессов отличается. Никто в своём уме не предусматривает использование только каменных топоров в техпроцессе, на случай если техпроцесс придётся запускать в джунглях острова Борнео. Так что «это просто инструмент» - так себе аналогия. Это не просто инструмент - это целая сеть условий, связанных с языком программирования. Целевые платформы, наличие легаси кода, наличие программистов, простота переучивания, идиосинкразии руководства, доступность библиотек, быстродействие, и т.д. и т.п.

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

Вон, уже сам Страуструп пишет статьи в духе «чуваки, кажется мы движемся куда-то не туда».

индеец Зоркий глаз заметил, наконец

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

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

на гитхабе гуглятся некоторые компактные реализации лиспов, например, такой макросами раста: JunSuzukiJapan/macro-lisp , murarth/ketos swgillespie/rust-lisp, jsdf/lisp.rs, mal (с реализацией на 10500 языках, включая пару на расте), записки в бложиках раз два

также есть очень любопытный минималистичный rui314/minilisp. хоть он и на Си, код меньше тысячи строк и есть `nogc branch`, что бы это ни значило.

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

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

я читал диссер Недори, который делал Mythril а потом из него получился XDS. там SSA представление, реализация на модуле-2 общего ядра для C/Modula-2/Oberon-2, оптимизации этого SSA.

в общем, такой LLVM в миниатюре :)))

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

<langname> всех порвёт

это выражение из ряда пассатижи погубят плоскогубцы.

in the beginning there was command line: вполне себе сравнивает бытовые дрели (винда/мак/ракомотофон) и строительные (линукс). если первая с защитой от дурака тупо сгорит, вторая намотает тебя и порвёт как тузик грелку.

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

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

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

В С++ уже пару лет как делают. В этом же недоязычке ещё перегрузку не осилили - какая там либа.

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

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

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

к примеру, смотрю я на недолисп mal, на реализацию на святой сишечке, обучающее видео dramatized demonstration. а потом на malc, который может LLVM биткод генерировать.

и вижу идею: понимаю, что инфраструктура LLVM + mal + malc делает ненужным трюки типа «лисп написан на себе самом», и прочие типа самораскрутки «sbcl на sbcl». особенно если заменить этот недолисп на более полноценный. при этом LLVM интегрируется с С, на том же clang ast можно написать плагином генерацию лисповых FFI и прочее.

и что в общем такая инфраструктура лучше с С интегрируется, и вполне себе может импортозаместить sbcl со временем. внутренние потроха которого понимают только диды, ога. конкретная реализация недолиспа mal тут не важна даже, важна идея. дух самораскрутки vs. дух нескольких, возможно скриптовых реализаций + нормальная, поддерживаемая инфраструктура типа llvm.

сколько там мечтали на sbcl Lisp OS запилить, да так полноценную и ниасилили? а тут на тебе, только вылупилось и уже qemu без особых сложностей.

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

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

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

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

В этом же недоязычке ещё перегрузку не осилили

в крестах талмуды пишут о том, как работает перегрузка.

void foo(const int &a) { cout << "foo\n"; }
void foo(int &&a) { cout << "bar\n"; }

int main() {
  int &&a = 5;
  foo(a);
}
угадайте с одного раза, что оно выведет. Тащить это дерьмо еще и в раст? Нет уж, спасибо.

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

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

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

компилятор предоставляет только процессор потока лексем, причем настолько неудобный, что над лексемами наворотили враппер а к нему в довесок сторонний компилятор, собирающий АСТ

Это в Расте такое безобразие?

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

А где еще. DSLи надо же как-то писать. Спасибо хоть строго лексят инпут и не дают всяким редискам сделать из языка балаган.

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

А где еще. DSLи надо же как-то писать. Спасибо хоть строго лексят инпут и не дают всяким редискам сделать из языка балаган.

Речь очевидно идет про то, как реализована поддержка макросов в компиляторе? Или весь компилятор такое?

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

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

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

А нафига вообще такое писать `int &&a = 5`? В каком случае может пригодиться?

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