LINUX.ORG.RU

Rust 0.10

 ,


2

8

Вышла новая версия Rust, языка программирования разрабатываемого Mozilla. Релиз несет в себе около 1500 изменений и исправлений ошибок.

Основные изменения:

  • Язык:
    • новый процесс RFC для изменения языка;
    • паттерны с '@'-указателями удалены из языка;
    • паттерны с '~[T]'-векторами удалены из языка;
    • паттерны с '~str'-строками удалены из языка;
    • '@str' удален;
    • '@[T]' удален;
    • '@self' удален;
    • '@Trait' удален;
    • заголовки, содержащие '@'-boxes для подсчета ссылок внутри типа, при '~'-аллокациях удалены;
    • семантика времени жизни временных выражений (temporary expressions) изменена. Подробнее в #3511, #11585;
    • добавлен новый cross-crate синтаксис расширений (доступен через feature gates). Подробнее в #11151. Эта возможность включает в себя макросы 'macro_rules!' и 'format!' как синтаксические расширения;
    • добавлены новые режимы lint, использование старых по умолчанию выдает предупреждения:
      • лишние скобки;
      • static в верхнем регистре;
      • Camel Case типы;
      • переменные в верхнем регистре;
      • приватные типы с публичной видимостью;
      • '#[deriving]' с raw-указателями.
    • unsafe-функции больше не преобразуются к замыканиям;
    • некоторые макросы с неясными названиями, например 'log_syntax!', теперь доступны через feature gates;
    • атрибут '#[simd]' теперь доступен через feature gates;
    • запрещены инструкции 'extern crate' в настройках видимости, модификатор 'priv' запрещен к использованию вместе с 'use' инструкциями;
    • замыкающие запятые запрещены в списках аргументов и шаблонах кортежей;
    • ключевое слово 'do' теперь является резервированным ключевым словом;
    • добавлены параметры типов по умолчанию, доступно через feature gates;
    • изменен механизм захвата borrowed-переменных в замыкания;
    • 'extern mod' изменен на 'extern crate';
    • удален 'Freeze' trait;
    • добавлен 'Share' trait для типов которые могут разделяться между потоками;
    • labels в макросах теперь гигиенические;
    • вызовы макросов теперь могут ограничиваться через '{}';
    • добавлен возможность перегрузки операторов '*' и '.' через 'Deref' и 'DerefMut' traits;
    • '~Trait' и 'proc' больше не реализуют 'Send' по умолчанию;
    • добавлена поддержка partial type hints через маркер типа '_';
    • введен тип 'Unsafe' для внутренней мутабельности. Преобразование '&T' в '&mut T' без использования 'Unsafe' является неопределенным;
    • реализован атрибут '#[linkage]' для внешних функций;
    • внутренний синтаксис атрибутов изменен с '#[foo];' на '#![foo]';
    • 'Pod' переименован в 'Copy'.
  • Библиотеки:
    • 'libextra' более недоступна. Она была разделена на более мелкие компоненты. Подробности в документации;
    • 'std::condition' удален. Все ошибки I/O передаются через тип 'Result'. Изменена работа макроса 'try!', подробности в #12039;
    • std: модуль 'vec' переименован в 'slice';
    • std: добавлен новый тип 'Vec<T>' для DST. В будущем это будет единственный вектор с изменяемым размером;
    • std: увеличено число публичных reexports 'std::io'. Типы, такие как 'BufferedReader' доступны через 'std::io::BufferedReader' вместо 'std::io::buffered::BufferedReader';
    • std: 'print' и 'println' более не доступны в prelude, используйте вместо них макрос 'println!';
    • std: 'Rc' теперь имеет 'Weak' указатель для прерываемых циклов и больше не пытается статически предотвращать циклы;
    • std: в стандартной поставке используется политика обработки ошибок пользователем вместо падения в библиотеках. Многие функции, такие как 'slice::last()' теперь возвращают 'Option<T>';
    • std: 'fmt::Default' переименован в 'fmt::Show', добавлен новый deriving mode: '#[deriving(Show)]';
    • std: 'ToStr' реализован для всех типов, реализующих 'Show';
    • std: trait для форматированного вывода принимает '&self' вместо '&T';
    • std: метод итераторов 'invert()' был переименован в 'rev()';
    • std: добавлена возможности вывода backtrace при падении task'a, если выставлено значение переменной 'RUST_BACKTRACE';
    • std: стандартизованы соглашения по наименованию для итераторов. Подробнее в wiki;
    • std: 'eof()' удален из 'Reader';
    • std: сетевые типы (networking types) теперь cloneable, разрешено одновременное чтение/запись;
    • std: 'assert_approx_eq!' удален;
    • std: добавлены спецификаторы форматирования 'e' и 'E' для вывода чисел с плавающей точкой в экспоненциальном формате;
    • std: удален 'Times';
    • std: добавлен тип 'std::kinds::marker' для выборочного вывода встроенных привязок (bounds);
    • std: 'hash' был переписан, 'IterBytes' удален, доступен '#[deriving(Hash)]';
    • std: 'SharedChan' был удален, 'Sender' теперь cloneable;
    • std: 'Chan' и 'Port' были переименованы в 'Sender' и 'Receiver';
    • std: 'Chan::new' заменен на 'channel()';
    • std: реализован новый тип синхронных каналов;
    • std: макрос 'select!' доступен для выбора 'Receiver'-ов;
    • std: 'hashmap' и 'trie' были перемещены в 'libcollections';
    • std: 'run' перемещен в 'io::process';
    • std: 'assert_eq!' теперь использует '{}' вместо '{:?}';
    • std: реорганизованы механизмы сравнения и проверки на равенство trait-ов;
    • std: 'rand' перемещен в 'librand';
    • std: 'to_{lower,upper}case' реализован для 'char';
    • std: функциональность логгирования перенесена в 'liblog';
    • collections: 'HashMap' переписана для увеличения производительности и уменьшения потребления памяти;
    • native: в качестве рантайма по умолчанию используется 'libnative'. 'libgreen' доступен для загрузки вручную, подробнее в документации;
    • native: реализована весь I/O функционал, за исключением сигналов;
    • green: оптимизировано создание task-ов в 'libgreen';
    • green: task-и, создаваемые через 'libgreen' используют unmapped guard page;
    • sync: модуль 'extra::sunc' был обновлен на современный rust, перемещен в библиотеку 'sync';
    • sync: добавлен новый тип 'Barrier';
    • sync: реализованы эффективные мьютексы для нативных и зеленых task-ов;
    • serialize: улучшен модуль 'base64';
    • fourcc: добавлен макрос 'fourcc!';
    • hexfloat: реализован макрос 'hexfloat!';
  • Инструментарий
    • 'rustpkg' объявлен устаревшим и удален из основного репозитория. Его замена ('cargo') в разработке;
    • доступны ночные сборки;
    • значительно улучшено использование памяти 'rustc';
    • отключена поддержка rpath для rustc в процессе сборки;
    • улучшен механизм кодогенерации;
    • восстановлена совместимость debuginfo с lldb на OSX;
    • флаги вывода централизованы в один флаг '--emit';
    • флаги crate типов централизованы в один флаг '--crate-type';
    • флаги кодогенерации объединены через флаг '-C';
    • улучшены сообщения об ошибках возникающих при линковке с устаревшими crates;
    • сообщения об ошибках с временем жизни теперь часто показывают как объявить функцию чтобы исправить ошибки;
    • значительно расширена документация;
    • улучшения в 'rustdoc':
      • подсветка синтаксиса и блоки кода;
      • генерация standalone markdown файлов;
      • флаг '--test' проверяет все блоки кода по умолчанию;
      • отображение экспортированных макросов;
      • reexported типы имеют встроенную документацию в месте первого reexport;
      • результаты работы по поиску в crate-ах теперь генерируется в выходную директорию.

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

★★★★★

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

А что плохого в C++? Нормально со своими задачами справлялся всегда. Что-то посовременнее, без старого наследия, но мощное, а не убогое, я бы посмотрел. Вроде scala после java.

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

А что плохого в C++?

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

Да, на практике иногда нет выбора, кроме как С++ и это печально.

«нормально справляется» - _нормально_ это очень растяжимая штука.

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

Есть типы, есть объекты, объединяющие в себе методы и состояние, есть полиморфизм. Что тебе еще надо для оопе-счастья?

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

И почему это не подходит под твое понимание ООП? Тебе нужны заголовочные файлы, конструкторы и ключевое слово 'class', что бы спать спокойно?

начнем с простого, как в rust будет выглядеть такое:

struct A {
  int  n = 1;
  bool f = false;
};

?

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

Ошибка компиляции? n же не инициализирован. Допустим, ты опустил конструктор.

struct A { n: int }
impl A {
    pub fn new() -> A { A{n: 0} }
    pub fn value(&self) -> int { self.n }
}
ozkriff
()
Ответ на: комментарий от anonymous

Плюешься на исключения - не используй их

Вот они их и не используют. Совсем.

чтобы писать в ОО-стиле приходиться подпрыгивать

Что не так с ООП в Rust?

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

Хээй, ты удалил комментарий. ( К чему ты вел-то?

ни к чему :) просто хотел узнать, но потом сам открыл документацию и прочитал

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

Открой Буча, открой Майерса, потом попробуй использовать ООП в расте. Тебе придётся вводить всякие лишние промежуточные звенья.

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

Кто они? Пусть не используют. Но если я захочу из использовать, мне раст не подойдёт :( Какая же это замена плюсам?

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

если я захочу из использовать, мне раст не подойдёт :(

Да, если тебе необходимы исключения, Rust тебе не подойдет. Капитан согласно кивает.

Какая же это замена плюсам?

Я обещаю подумать над этим вопросом, если ты приведешь мне цитату какого-нибудь из создателей Rust «Мы пишем замену плюсам».

Заменой плюсам должен был стать D - в нем есть всё. И где он? Всем пофиг на feature parity с плюсами.

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

Я не троллю. Там нет ООП, но его можно эмулировать посредством trait'ов и impl'ов Если я не прав - ткни носом в описание ОО-плюшек в доках.

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

А что плохого в C++?

Головоломная сложность.

Чего там сложного?

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

Но понт засчитан, да.

Все нормальные языки сложны

Не во всех «нормальных языках» это следствие извилистых путей дизайна.

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

Утверждения о замене плюсам тут уже звучали.

И это значит... совершенно верно - что 66% фишек плюсов нафиг не нужны в реальности.

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

То, что там нет ООП.

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

Открой Буча, открой Майерса, потом попробуй использовать ООП в расте. Тебе придётся вводить всякие лишние промежуточные звенья.

Потому что это не С++ и книжки буча и майерса тут в лоб не применимы. И причем это тут? Развернутый пример помог бы тебе донести свою мысль.

... если я захочу из использовать, мне раст не подойдёт :( Какая же это замена плюсам?

Замена не должна быть 1 в 1 тем, что она заменяет, какой в этом смысл? Ты можешь применять Ржавчину для решения тех же задач, для которых бы подошел С++, так что это замена.

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

Чего там сложного?

Т.е. ты тот единственный гуманоид, который на 100% знает всю ту серную анальную содомию, которую из себя представляют плюсы?

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

Я не знаю, о какой содомии речь. Плюсы не сильно сложнее scala. И сложность эта вполне оправдана. И даже язык развивается вполне себе. На 100% нет смысла знать, всегда есть доки.

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

Тьфу ты, я про Мейера, а не Майерса. Тот, который Бертран. Он C++ не любит, а книжка по ООП у него годная.

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

Зачем 1 в 1? Но возможности зачем ограничивать?

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

Option: http://static.rust-lang.org/doc/master/std/option/index.html
Result: http://static.rust-lang.org/doc/master/std/result/enum.Result.html

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

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

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

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

Я не знаю, о какой содомии речь.

Значит плохо плюсы знаешь или мало на них писал, как мне видится.

scala .. scala .. scala

Про scala ничего не могу сказать, у меня аллергия на все эти java, c# и подобное.

И сложность эта вполне оправдана.

Единственное (очень очень спорное) оправдание - обратная совместимость. Если мне она не нужна, то я просто получаю кучу лишней сложности и все.

И даже язык развивается вполне себе.

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

Тьфу ты, я про Мейера, а не Майерса. Тот, который Бертран. Он C++ не любит, а книжка по ООП у него годная.

Не читал, как-нибудь ознакомлюсь.

Зачем 1 в 1? Но возможности зачем ограничивать?

Допустим, вот зачем (ссылка уже была но она тут подходит, как мне кажется): http://250bpm.com/blog:4

Ты не можешь просто так взять и сказать «я не использую исключения, моя жизнь теперь прекрасна».

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

// А если реализация библиотеки изменилась и
// теперь кидаются другие исключения?

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

Конечно, в Расте в этом случае, им придётся меня сигнатуру (раньше всегда возвращали Т, теперь стало Result<T, E>) и компилятор про это скажет.

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

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

Option позволяет вернуть результат или «ничего», а Result - результат или информацию об ошибке? Второго в С++ нет

А первое что - есть? Ну да, есть Boost.Optional, но там же есть и Boost.Variant.

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

Правильно я понимаю ...

Вроде, правильно.

Исключения бывают удобны, ...

Бывают удобны. А бывают неудобны и очень опасны.

... плюс использовать их не обязательно.

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

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

А что мешает каждую функцию в try catch обернуть?

Потому что это получится ничем не лучше кодов возврата. В этом случае, как раз исключения не удобны. Но они удобны, когда ошибку надо обработать уровнем (или нескольким) выше. И чтобы не писать фигню типа:

bool f()
{
    if(!a())
    {
        return false;
    }
    if(!b())
    {
        return false;
    }
    ...

    return true;
}
Потому, в идеале, лучше иметь две версии функции - с исключениями и без.

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

чтобы не писать фигню типа:

Можно написать макрос do_!:

     let x = do_!(bind a = Some(1);
                  bind b = None;
                  let res = a + b;
                  Some(res));

https://mail.mozilla.org/pipermail/rust-dev/2013-May/004176.html

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

Что-то посовременнее, без старого наследия, но мощное, а не убогое, я бы посмотрел. Вроде scala после java.

+1. Но никто такого делать не собирается, вроде.

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

Неопределенное поведение на каждом углу.

Интересно по каким углам ты шаришься, что постоянно UB встречаешь?..

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

Заменой плюсам должен был стать D - в нем есть всё. И где он? Всем пофиг на feature parity с плюсами.

Там нет множественного наследования, например.

(Я не считаю это фатальным недостатком, если что.)

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

Звучит как сложности на пустом месте. Можно сделать все просто и аккуратно, но мы пойдем другим путем...

И это же не единственная претензия к исключениям.

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

Так что я вижу их полное отсуствие в языке как нечто хорошее.

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

А первое что - есть? Ну да, есть Boost.Optional

std::optional почти есть, ну и буст, да. Причём boost::optional как раз широко используется в самом бусте именно как Option. Вполне удобно, в рабочих проектах тоже часто применяется.

но там же есть и Boost.Variant.

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

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

Если мне она не нужна, то я просто получаю кучу лишней сложности и все.

«К сожалению», если бы не совместимость, то язык быстро закопали бы.

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

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

Ну нет. Мой опыт (пусть и не мега огромный) говорит обратное. Да, разумеется, бывают «внезапные эксепшены» там где их не ожидаешь. Но это ничем не отличается от забытой проверки кода возврата и подобной фигни. Без тестирования никуда не деться.

В статье " Why should I have written ZeroMQ in C, not C++", на мой взгляд, примеры слишком искусственные.

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

А первое что - есть? Ну да, есть Boost.Optional

std::optional почти есть

Не прошло и 30 лет... хотя, до появления в стандарте может пройти и больше.

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

variant (как и enum в Rust) - это просто конструктор ADT; совершенно необязательно конструировать тип «значение | ошибка».

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

Можно написать макрос do_!:

Ну (дурацкий и не эквивалентный, да) макрос можно и в С:

bool f() {
    CHECK(a());
    CHECK(b());
    ...
Впрочем, про твой вариант тоже пишут, что не всё замечательно:

but there's no generic return equivalent yet, so that has to be changed for each type

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

Нигде не надо шариться. Большая программа на плюсах - поле с UB-граблями.

Я искал, с чем бы сравнить программирование на С++ и я вспомнил фильм 1990 года режиссера Тима Бертона — «Эдвард руки-ножницы»
Это темная версия Пиноккио, снятая в атмосфере пригорода. В этом фильме жуткий парень (Джонни Депп) пытается аккуратно обнять Ванону Райден, но его неуклюжие руки-ножницы делают это очень опасным для них обоих. Его лицо уже покрыто глубокими шрамами.
Если у вас ножницы вместо рук, то это не так уж и плохо. У Эдварда много талантов: например, он может потрясающе стричь собак!
Меня часто посещают похожие мысли после посещения С++ конференций: в этот раз это было после Going Native 2013. В прошлом году были восторги и волнения по поводу нового стандарта — С++11. В этом году это было проверкой в реальных условиях. Не поймите меня неправильно: там было много потрясающих собачьих причесок (я имею в виду код на С++, который был простым и элегантным), но основная часть конференции была о том, как избежать увечий и оказать первую помощь в случае нечаянной ампутации.

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

Вроде как, D более менее подходит, не?

Более-менее. (:

Мне не очень нравится, например, что для классов обязательно ГЦ использовать и подобные «мелочи».

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

дурацкий и не эквивалентный, да

Даже не похожий %)

про твой вариант тоже пишут, что не всё замечательно:

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

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

Так что я вижу их полное отсуствие в языке как нечто хорошее.

Ну а я нет. Впрочем, начинать тут ещё один холивар на эти тему и правда не интересно.

Звучит как сложности на пустом месте.

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

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

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