LINUX.ORG.RU

Релиз языка программирования Rust 1.39

 ,


1

8

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

Что нового в версии 1.39:

  • стабилизирован новый синтаксис асинхронного программирования, основанный на функции «async», блоке async move { … } и операторе «.await»;
  • разрешено указание атрибутов при определении параметров функций, замыканий и указателей на функции. Поддерживаются атрибуты условной компиляции (cfg, cfg_attr), управляющие диагностикой через lint и вспомогательные атрибуты вызова макросов;
  • стабилизирован «#feature(bind_by_move_pattern_guards)», который позволяет использовать переменные с типом привязки «by-move» в шаблонах;
  • предупреждения о проблемах при проверке заимствования переменных c использованием NLL переведены в разряд фатальных ошибок;
  • в пакетный менеджер cargo добавлена возможность использования расширения «.toml» для файлов конфигурации.

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

>>> Источник

★★★★★

Проверено: cetjs2 ()

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

Потому что спецификация T относится именно к имплементации, а не к BTree.

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

impl<A, B, C> задаёт входящие параметры-типы и их ограничения в одном месте. Как в С переменные определяются только в начале функции.

Что должно значить impl Trait<T: Ord> for BTree<T: Eq>?

Можно наверно от этого явного объявления типов избавиться, но пока никто не занялся.

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

Но для функции спецификацию T мы же можем указать как fn some_func<T>(x: T) -> T where T: Ord + Eq {

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

impl<A, B, C> задаёт входящие параметры-типы и их ограничения в одном месте.

Но у функций может быть по другому. Через тот же `where`, что как по мне более приятней.

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

В impl тоже можно where написать.

impl<T> Foo<T>
where T: Clone
{
    fn bar(&self) {}
}
red75prim ★★ ()
Ответ на: комментарий от WatchCat

Имплементация структуры и сама структура по идее - разные вещи. Я сталкивался с этим. Тут будет U, например, а там - T. И это разные штуки.

Еще такая хрень будет у тебя когда-нибудь impl<'a, T: 'a> AAA<'a> for BBB<T>

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

А некоторые хотят implement Write for Foo { public function bar(&self) -> boolean {} }. Вкусы у всех разные.

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

Ну это же просто неправда! Ocaml не сложнее питона или go какого-нибудь.

Вы на Окамле писали? Я писал. Гораздо сложнее Питона и сложнее Го однозначно. Именно в смысле логики построения кода. Это только в примерах у них на сайте всё кажется просто. А в действительности, если пишем что-нибудь серьёзное, чтобы всё сидело во сложенных функциях, вы производные типы данных и операторы над ними вводить и согласовывать ошизеете.

В питоне всё просто: засунул что попало в кортеж или словарь, потом дёрнул оттуда по номеру или ключу. При этом тип объявлять не надо и легко переписать. В Окамле так не выйдет: если засунул в кортеж, будешь дёргать по одному, список не может содержать произвольные функции, если тип вывода из функции изменился, изволь переписать весь код, если тип переменный, изволь предусмотреть это явно. В Питоне всегда можно изменить значение переменной, а Окамле — не всегда и не всякой.

В Питоне можно писать чисто императивно: делай то-то. В Окамле только кажется, что так можно делать, да и то только на верхнем уровне. На самом деле это довольно сложно оформить, если в функции несколько циклов с условиями внутри, проще разложить на подфункции и переделать в цепочки вызовов.

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

А некоторые хотят implement Write for Foo { public function bar(&self) -> boolean {} }. Вкусы у всех разные.

Дело не во вкусах, дело в количестве сущностей, которые ты выписываешь и используешь. Какие там будут кейворды дело десятое. К примеру в Option<Box<Node<’a>>> сразу четыре сущности, а в Node? - всего две. Тут

 impl<’a> Node<’a> { 
     pub fn insert(&mut self, new_val: &’a str) { 

Их 13 (плюс-минус), а тут:

 public func insert(new_val: String) 

Их 5. Проще код - проще писать, проще читать и переваривать, меньше ошибок, большая продуктивность.

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

И так тихо и незаметно подменил str на String. Тогда сразу писать на жабе остается!

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

И так тихо и незаметно подменил str на String.

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

Тогда сразу писать на жабе остается!

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

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

Что такое Node?? Владеющий nullable указатель на Node, аллоцированный дефолтным аллокатором? Те же пять сущностей.

Или больше? Swift кажется ещё ARC добавляет?

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

Ничего, что в примере на Rust хранится ссылка на строку, а не строка?

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

Т.е. одну и ту же вещь двумя разными путями описываем, впрчем как и у функции.
КМК это не очень хорошо.
Стоило бы оставить только один вариант.

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

как в каком-нибудь Swift

Только Swift медленнее. За удобство приходится платить.

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

Для коротких типов - проще через :, для сложных - проще через where. Всё для людей.

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

Что такое Node?? Владеющий nullable указатель на Node, аллоцированный дефолтным аллокатором? Те же пять сущностей.

Node? это сахар к Optional. А место хранения уже зависит от типа объекта. Для экземпляров классов используется ARC. Но дело не в этом, если копнуть глубже (что для Rust ты не сделал), то и там сущностей прибавится. Для этого и нужны абстракции, чтоб детали реализации можно было просто помнить (и то не обязательно, если ты новичок).

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

Только Swift медленнее. За удобство приходится платить.

Да, в основном за счет совместимости с ObjC. Apple не ставила за цель сделать идеальный язык, им надо было иметь совместимость с legacy.

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

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

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

Ну сделай алиас Option = OptBox

В таких случаях корректно сравнивать только дефолтные реализации и способы. Иначе придет какой-нибудь лиспер с DSL и скажет, что это все делается в одну строку.

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

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

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

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

Ничего, что в примере на Rust хранится ссылка на строку, а не строка?

В С++ тоже можно взять string_view, или использовать rvalue reference, не думал, что это принципиально.

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

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

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

Начинающий сишник - это особый вид людей, со встроенным пониманием указателей?

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

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

Я в общем о том-же. Скомпилировал, запустил, упало, шишка. Приходится разбираться. Впрочем с unsafe кодом примерно такая-же история.

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

И что, Ада тоже мертвая?

а fortran мертвый?

ну в контексте популярности rust&go относительно d

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

В С++ тоже можно взять string_view

(since C++17)

Ну возьми.

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

У нас тут есть начинающие сишники на лоре - большего треша представить сложно.

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

(since C++17) Ну возьми.

Давно доступно в clang(libc++), gcc(libstdc++) и msvc.

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

Ну и если почитать сообщения по ссылке, то можно найти:

So I think that after the lengthy discussion here, this issue can now be closed. In summary: the use-after-free potential with string_view is accounted for in the Lifetime profile, even if there may be bugs or limitations in preliminary implementations that mean it is not diagnosed.

https://imgur.com/a/bRCAbcr

C26484

Лайфтаймы в С++ 2019 это реальность, благодаря MSVC и Clang.

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

Вау, 1% фич Rust теперь C++. Бегом переписывать всё снова на С++.

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

Бегом переписывать всё снова на С++.

Пока еще особо и нечего назад переписывать.

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

Если бы он был разумно спроектирован и продуман, то осваивать его можно было бы быстро и через пару недель начинать писать на нём. Как на go, например.

осваивателей ЯП «за две недели» надо топить, пока они маленькие ещё.

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

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

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

А теперь давайте проверим многопоточный код.

https://clang.llvm.org/docs/ThreadSafetyAnalysis.html

Использую, отлично справляется со своими задачами.

Ну или хотя бы инвалидацию итераторов.

В Visual C++ 2019 есть. По сути там как в Rust:

One rule classifies containers as an ‘Owner’. Then, when a non-const method is called on the Owner, its owned memory is assumed invalidated and iterators that point at the owned memory are also considered invalid.

В clang есть наработки на эту тему:

http://llvm.org/devmtg/2018-04/slides/Balogh-Finding%20Iterator-related%20Errors%20with%20Clang%20Static%20Analyzer.pdf

Они уже в clang, но они пошли более сложным путем, реально пытаясь анализировать - ломается итератор или нет. А значит это не так надежно и универсально как метод в Rust или Visual C++.

Или ещё лучше - пусть он мне найдет все неинициализированные переменные статически. Я так и не нашёл как это сделать.

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

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

Но можно легко написать свой чекер на питоне.

Вы точно поняли суть задачи?

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

Вы точно поняли суть задачи?

Значит вы не описали свою просьбу достаточно информативно.

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

Я правильно понимаю, что оно работает только с кастомным мютексом и все переменные должны быть помечены вручную?

Нет, не только, в стандартной библиотеке есть все что надо. Что касается «должны быть помечены вручную», вы точно понимаете, что оно делает и что такое вообще «Thread Safety Analysis»?

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

Я в курсе что оно делает. Вопрос был а том, можно ли реализовать эти проверки без модификации кода.

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

Я в курсе что оно делает. Вопрос был а том, можно ли реализовать эти проверки без модификации кода.

Значит, очевидно, не в курсе и не понимаете, что это вообще такое.

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

Ну весело да, как кич некий, я ж не спорю об этом

ну тогда я тебя не понял )

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

ну а тут ты меня не понял, ни в одном месте я не ставлю это в один ряд с достойными вещами в интернетах

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

осваивателей ЯП «за две недели» надо топить, пока они маленькие ещё.

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

А профессиональный снобизм до добра не доводит.

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

а fortran мертвый?

Вполне живой. Писал на нём программу в этом году, кстати.

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

Любой начинаюший сишник понимает в этом больше чем растер,

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

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