Мы рады представить новую версию Rust 1.12. Rust — это системный язык программирования, нацеленный на безопасную работу с памятью, скорость и параллельное выполнение кода.
Как обычно, вы можете установить Rust 1.12 с соответствующей страницы официального сайта, а также ознакомиться с подробным списком изменений в этой версии на GitHub. В этот выпуск вошёл 1361 патч.
Что вошло в стабильную версию 1.12
Выпуск 1.12 — возможно, самый значительный с момента выпуска 1.0. Нам есть о чём рассказать, но если у вас мало времени, вот краткое содержание.
Самое заметное для пользователей изменение в 1.12 — это новый формат ошибок, выдаваемых rustc. Мы говорили о нём раньше и это первый стабильный выпуск, где новый формат доступен всем. Эти сообщения об ошибках — результат многочисленных усилий добровольцев, которые спроектировали, протестировали и обновили каждую ошибку rustc в соответствии с новым форматом. Нам интересно узнать, что вы думаете о новых ошибках:
Самое большое внутреннее изменение — переход на использование нового бэкенда компилятора, основанного на Rust MIR (англ. Medium Intermediate Representation). Хотя эта особенность на данный момент не даёт нам ничего видимого пользователям, она прокладывает путь для нескольких будущих оптимизаций компилятора, и для некоторых кодовых баз она уже обеспечивает увеличение скорости компиляции и уменьшение размера сгенерированного кода.
Переработанные сообщения об ошибках
В 1.12 мы представляем новый формат сообщений об ошибках. Он подробно отражает причины, по которым компилятор отказывается компилировать ваш код. Для этого мы помещаем ваш код в центр внимания и подсвечиваем части, которые важны в каждом конкретном случае. Мы также аннотируем каждое ошибочное место и подробно описываем, что пошло не так.
Например, если реализация типажа не совпадала с его объявлением в 1.11, вы видели такую ошибку:
В новом формате мы в первую очередь показываем самые важные части кода. В данном случае это строка объявления типажа, строка его определения, и метки, указывающие на несовпадение:
Изначально мы разрабатывали такой вид ошибок, чтобы помочь в понимании проблем, о которых сообщал анализатор заимствований (англ. borrow checker). Но по ходу дела мы поняли, что этот формат может быть применён ко множеству разных ошибок — например, как в приведенном выше примере. Если вы бы хотели узнать о новой системе ошибок больше, смотрите предыдущий пост в блоге на эту тему.
Наконец, вы также можете получить эти ошибки в JSON с помощью флага. Помните ту ошибку, которую мы показали в начале поста? Вот как выглядит попытка скомпилировать тот код, передав ему при этом флаг --error-format=json:
$ rustc borrowck-assign-comp.rs --error-format=json
{"message":"cannot assign to `p.x` because it is borrowed","level":"error","spans":[{"file_name":"borrowck-assign-comp.rs","byte_start":562,"byte_end":563,"line_start":15,"line_end":15,"column_start":14,"column_end":15,"is_primary":false,"text":[{"text":" let q = &p;","highlight_start":14,"highlight_end":15}],"label":"borrow of `p.x` occurs here","suggested_replacement":null,"expansion":null}],"label":"assignment to borrowed `p.x` occurs here","suggested_replacement":null,"expansion":null}],"children":[],"rendered":null}
{"message":"aborting due to previous error","code":null,"level":"error","spans":[],"children":[],"rendered":null}На самом деле мы опустили некоторые детали в целях краткости, но идея понятна. Этот вывод в основном предназначен для инструментов; мы продолжаем работать над поддержкой IDE и других полезных инструментов разработчиков. Такой вид вывода ошибок — маленькая часть этой работы.
Кодогенерация через MIR
Новое промежуточное представление среднего уровня (англ. mid-level IR), которое мы обычно называем "MIR", даёт компилятору возможности проще работать с кодом на Rust, чем это было раньше — когда он обрабатывал абстрактное синтаксическое дерево Rust. MIR делает возможными проверки и оптимизации, которые раньше считались невозможными. Первое из грядущих изменений компилятора, которое стало доступно благодаря MIR — переписывание прохода, генерирующего LLVM IR — того, что rustc называет "трансляцией". После многих месяцев работы MIR-бэкенд наконец готов к выступлению на большой сцене.
MIR содержит точную информацию о потоке управления программы, поэтому компилятор точно знает, перемещены типы или нет. Это значит, что он статически знает, нужно ли выполнять деструктор значения. В случаях, когда значение может быть перемещено или не перемещено в конце блока, компилятор использует флаг всего из одного бита на стеке, что намного лучше поддаётся оптимизации со стороны LLVM. Конечный результат — это меньше работы для компилятора и менее раздутый код во время исполнения. А ещё на MIR проще реализовывать новые проходы компилятора и проверять, что они работают правильно — потому что MIR — более простой "язык", чем полное AST.
Другие улучшения
- Много небольших улучшений в документации.
rustcтеперь поддерживает три новые цели на ARM с MUSL:arm-unknown-linux-musleabi,arm-unknown-linux-musleabihfиarmv7-unknown-linux-musleabihf.
Эти цели производят статические исполняемые файлы. Однако, в собранном виде они пока не распространяются.- Ссылки и неизвестные числовые типы теперь лучше показываются в сообщениях об ошибках.
- Компилятор теперь может быть собран на LLVM 3.9
- Исполняемые файлы тестов теперь поддерживают аргумент
--test-threads, указывающий число потоков, используемых для выполнения тестов. Также этой настройкой управляет переменная окружения
RUST_TEST_THREADS - Запускалка тестов теперь показывает предупреждение, если выполнение тестов занимает больше 60 секунд
- Вместе с выпусками Rust теперь доступны пакеты исходников, которые могут быть установлены rustup с помощью команды
rustup component add rust-src.
Полученный исходный код может быть использован инструментами и IDE, и расположен в sysroot в директорииlib/rustlib/src.
Подробнее смотрите замечания к выпуску.
Стабилизация библиотек
В этом выпуске многими типами стало немного удобнее пользоваться.
Cell::as_ptrиRefCell::as_ptrIpAddr,Ipv4AddrиIpv6Addrполучили несколько новых методов.LinkedListиVecDequeполучили методcontains.iter::Productиiter::SumOptionреализуетFromдля содержащегося в нём типаCell,RefCellиUnsafeCellреализуютFromдля содержащегося в них типаCow<str>реализуетFromIteratorдляchar,&strиString- При использовании
SOCK_CLOEXECсокеты на Linux правильно закрываются в подпроцессах StringреализуетAddAssign- Определения Юникода обновлены до версии 9.0
Подробнее смотрите замечания к выпуску.
Возможности Cargo
Самая интересная возможность, добавленная в Cargo в этом цикле — "workspace'ы." Они определены в RFC 1525, и позволяют группе пакетов разделять один и тот же файл Cargo.lock. Если вы занимаетесь проектом, который разделён на несколько пакетов, workspace'ы сильно упрощают фиксацию единственной версии общих зависимостей. В большинстве проектов включение этой возможности потребует добавления в Cargo.toml верхнего уровня единственной строчки, [workspace]. Более сложным проектам может потребоваться более хитрая настройка.
Другая значительная возможность — это перегрузка пути к исходному коду контейнера. Вы можете легко распространять зависимости локально (англ. vendoring), используя её в сочетании с инструментами вроде cargo-vendor и cargo-local-registry. Со временем на базе этого будет построена инфраструктура зеркал crates.io.
Ещё есть некоторые мелкие улучшения:
- Ускорены обновления, когда обновлять ничего не надо
cargo newполучил флаг--lib- После компиляции показывается время, которое занял этот процесс
cargo publishполучил флаг--dry-run
Подробнее смотрите замечания к выпуску.
Разработчики версии 1.12
В выпуске версии 1.12 участвовало 176 человек. Большое вам спасибо!
- Aaron Gallagher
- abhi
- Adam Medzinski
- Ahmed Charles
- Alan Somers
- Alexander Altman
- Alexander Merritt
- Alex Burka
- Alex Crichton
- Amanieu d'Antras
- Andrea Pretto
- Andre Bogus
- Andrew
- Andrew Cann
- Andrew Paseltiner
- Andrii Dmytrenko
- Antti Keranen
- Aravind Gollakota
- Ariel Ben-Yehuda
- Bastien Dejean
- Ben Boeckel
- Ben Stern
- bors
- Brendan Cully
- Brett Cannon
- Brian Anderson
- Bruno Tavares
- Cameron Hart
- Camille Roussel
- Cengiz Can
- CensoredUsername
- cgswords
- Chiu-Hsiang Hsu
- Chris Stankus
- Christian Poveda
- Christophe Vu-Brugier
- Clement Miao
- Corey Farwell
- CrLF0710
- crypto-universe
- Daniel Campbell
- David
- decauwsemaecker.glen@gmail.com
- Diggory Blake
- Dominik Boehi
- Doug Goldstein
- Dridi Boukelmoune
- Eduard Burtescu
- Eduard-Mihai Burtescu
- Evgeny Safronov
- Federico Ravasio
- Felix Rath
- Felix S. Klock II
- Fran Guijarro
- Georg Brandl
- ggomez
- gnzlbg
- Guillaume Gomez
- hank-der-hafenarbeiter
- Hariharan R
- Isaac Andrade
- Ivan Nejgebauer
- Ivan Ukhov
- Jack O'Connor
- Jake Goulding
- Jakub Hlusicka
- James Miller
- Jan-Erik Rediger
- Jared Manning
- Jared Wyles
- Jeffrey Seyfried
- Jethro Beekman
- Jonas Schievink
- Jonathan A. Kollasch
- Jonathan Creekmore
- Jonathan Giddy
- Jonathan Turner
- Jorge Aparicio
- Jose manuel Barroso Galindo
- Josh Stone
- Jupp Muller
- Kaivo Anastetiks
- kc1212
- Keith Yeung
- Knight
- Krzysztof Garczynski
- Loic Damien
- Luke Hinds
- Luqman Aden
- m4b
- Manish Goregaokar
- Marco A L Barbosa
- Mark Buer
- Mark-Simulacrum
- Martin Pool
- Masood Malekghassemi
- Matthew Piziak
- Matthias Rabault
- Matt Horn
- mcarton
- M Farkas-Dyck
- Michael Gattozzi
- Michael Neumann
- Michael Rosenberg
- Michael Woerister
- Mike Hommey
- Mikhail Modin
- mitchmindtree
- mLuby
- Moritz Ulrich
- Murarth
- Nick Cameron
- Nick Massey
- Nikhil Shagrithaya
- Niko Matsakis
- Novotnik, Petr
- Oliver Forral
- Oliver Middleton
- Oliver Schneider
- Omer Sheikh
- Panashe M. Fundira
- Patrick McCann
- Paul Woolcock
- Peter C. Norton
- Phlogistic Fugu
- Pietro Albini
- Rahiel Kasim
- Rahul Sharma
- Robert Williamson
- Roy Brunton
- Ryan Scheel
- Ryan Scott
- saml
- Sam Payson
- Samuel Cormier-Iijima
- Scott A Carr
- Sean McArthur
- Sebastian Thiel
- Seo Sanghyeon
- Shantanu Raj
- ShyamSundarB
- silenuss
- Simonas Kazlauskas
- srdja
- Srinivas Reddy Thatiparthy
- Stefan Schindler
- Stephen Lazaro
- Steve Klabnik
- Steven Fackler
- Steven Walter
- Sylvestre Ledru
- Tamir Duberstein
- Terry Sun
- TheZoq2
- Thomas Garcia
- Tim Neumann
- Timon Van Overveldt
- Tobias Bucher
- Tomasz Miasko
- trixnz
- Tshepang Lekhonkhobe
- ubsan
- Ulrik Sverdrup
- Vadim Chugunov
- Vadim Petrochenkov
- Vincent Prouillet
- Vladimir Vukicevic
- Wang Xuerui
- Wesley Wiser
- William Lee
- Ximin Luo
- Yojan Shrestha
- Yossi Konstantinovsky
- Zack M. Davis
- Zhen Zhang
- ???
Комментарии (44)
estin
03.10.2016 15:30+8Rust все продолжает привлекать к себе внимание core developers других языков. Вот и Georg Brandl в списке "участников". Для тех кто живет в мире Python известное имя. Возможно еще много кто есть в этом списке, просто Georg первая знакомая для меня персона из этого списка )
tgz
03.10.2016 15:40+10Вот как приятно смотреть как люди без лишего пиара и пафоса делают простой и красивый язык.
orcy
03.10.2016 20:56+3Пиара и пафоса вроде как раз довольно много, по моему наиболее «горячий» язык в новостях
ozkriff
03.10.2016 21:02+2лишего пиара и пафоса
Так разве они лишние? Вообще не продвигать язык нельзя — тогда пользователям-первопроходцам неоткуда будет взяться, а без них язык постепенно загнется.
tgz
04.10.2016 20:21+3Что-то я не заметил. Релизы у них частые, вот и кажется что много. Но ни в какое сравнение не идет как тут пеарили ту же гошечку.
AnisimovAndrey
03.10.2016 16:36+8Анонсируют то, что произойдёт в будущем. Там что слово «анонс» здесь неуместно.
Это в английском «to announce» — объявлять.
JDTamerlan
05.10.2016 01:00-2Я попробовал несколько подходов к изучению этого языка — к сожалению, впечатление осталось малоприятное.
Основная сложность — мне не удалось обнаружить красоту-симметричность структуры языка:
1) Send и Sync
2) используется множество сокращений, которые читаются куда хуже, чем полные названия, например в Qt
3) отсутствие ключевого слова и вообще точки с запятой при возврате значения в последней строке функции
Мне как-то вообще малопонятна его (языка) логика — откуда берутся такие решения? О чем думают авторы — об экономии символов кода вместо простоты и понятности?red75prim
05.10.2016 07:15+3Красота и симметрия в физике — это понятно. Различные симметрии соответствуют различным законам сохранения.
В программировании с этим как-то сложнее. Максимальное значение знакового целого в дополнительном коде 32768, минимальное -32767. Несимметрично, но проще для аппаратной реализации.
В OpenGL было принято решение перед отрисовкой приводить все координаты (x, y, z) к диапазону [-1; 1]. Видимо из соображений красоты/симметрии (в DirectX диапазон для z [0; 1]). Это привело к тому, Z-buffer имеет максимальную точность не вблизи камеры, а на некотором расстоянии, там где она не нужна.
Это первые контрпримеры, которые пришли на ум, к утверждению, что симметрия в программировании всегда полезна. Подтверждающие примеры, как-то не вспоминаются. Абстрактно-теоретическая симметрия между IEnumerable и IObservable, разве что. Впрочем, рассуждать о программировании в терминах симметрии я не привык, могу что-то и упустить.
1) Send, Sync — трейты-маркеры, обозначающие, что объект может безопасно передан в другой поток и что два потока могут безопасно использовать ссылку на один и тот же объект одновременно. Они, например, позволяют безопасно использовать Rc (указатель со счетчиком ссылок) вместо Arc (указатель с потокобезопасным счетчиком ссылок).
2) Спорное решение. Но не так уж их и много.
fn,pub,mut,impl,mod,Rc,Arc. Что ещё забыл? Я перестал замечать через час.
3) Язык ориентирован на выражения. Блок в фигурных скобках — это выражение, возвращающее последнее значение в блоке. Можно написать
let x = if y {a} else {b};илиfn id<T>(x: T) -> T {x}. Но можно, конечно, сделать иfn id<T>(x: T) -> T {return x;}.returnрекомендуется использовать только для раннего возврата значений из функции, если использоватьreturnтолько для этого, то ранний возврат легче заметить.ozkriff
05.10.2016 08:49… fn, pub, mut, impl, mod, Rc, Arc. Что ещё забыл? ...
Из ключевых слов еще вот сокращения:
- const
- enum
- priv
- proc
- ref
red75prim
05.10.2016 08:58+1Благодарю.
const,enumпривычны по C,privещё не используется,procуже не используется,refзабыл, спасибо.
Но, в любом случае, сокращений не так уж и много.
ozkriff
05.10.2016 09:02+1Да я так, для полноты картины)
privещё не используетсяОн тоже "уже": https://github.com/rust-lang/rust/issues/8122 :)
JDTamerlan
05.10.2016 10:38Спасибо за конструктивный ответ, в частности за прояснение логики по пункту 3.
симметрия в программировании всегда полезна. Подтверждающие примеры, как-то не вспоминаются.
Слово «всегда» я не говорил, но вот Вам некоторые примеры, подтверждающие красоту, простоту и понятность системно-симметричного подхода разработки ПО:
- constructor/destructor
- (), {}, [], <>, 'c', «string»
- + / -, ++ / --
- open/close
- read/write
- min/max
- begin/end
- lock/unlock
- show/hide
- create/destroy
- old/new
- first/last
- start/stop
Мне, например, такими конструкциями очень легко и приятно пользоваться.ozkriff
05.10.2016 10:43constructor
Что пользовательские конструкторы типов как часть языка вообще являются хорошей идеей согласны далеко не все.
ozkriff
05.10.2016 10:49+3… вот Вам некоторые примеры ...
А что конкретно в ржавчине жутко асимметрично без причины?
JDTamerlan
09.10.2016 01:11-1Посмотрел еще немного ассиметричности (без «жутко», которое я не говорил):
https://doc.rust-lang.org/book/strings.html#slicing (перемешивание байтов и чаров)
https://doc.rust-lang.org/book/strings.html#concatenation (два типа почти одинаковых строк конкатенируются несколько по-разному)
И причина в обоих случаях написана почему так сделано, но недостаток системности для меня неприемлем. Это просто мое мнение. Кому нравится — пусть программируют.
Прошу только поменьше мне ставить минусы за высказывание своего мнения, как за начальный комментарий. А то у меня еще возникнут и сложности в понимании логики оценивания людей :)ozkriff
09.10.2016 11:51+2slicing, concatenation
Во, это уже интереснее. Хотя это тоже уже очень много раз разобранные со всех сторон вопросы, про которые есть много статей. Про
String/&strвообще только ленивый не писал еще)
два типа почти одинаковых строк конкатенируются несколько по-разному
Они не по-разному соединяются, сам по себе
&strвообще не имеет операции соединения (это одолженная строка, она не владеет своими данными и не может ничего в них дописывать)..to_string()это как раз приведение&strкString.
без «жутко», которое я не говорил
Так и не цитата же была :) Я "жутко" добавил потому, что в любом инженерном решении, если достаточно пристально прикопаться, можно найти нестыковки и кривости разные, но внимания обычно заслуживает только какая-то их часть. Так же, многие кривости определяются врожденной кривостью самой предметной области и тут тоже не всегда что-то можно сделать, что бы совсем их убрать.
И причина в обоих случаях написана почему так сделано, но недостаток системности для меня неприемлем.
И то, и другое объясняется как раз тем что это системный язык и ему нельзя абстрагироваться от этих деталей, иначе ржавчина как язык вообще смысла бы не имела.
Да и строки это вообще отдельный разговор, абсолютное большинство языков отвратительно работает с текстом и скрывает от программиста кучу потенциальных ошибок.
Недостаток скорости в системном языке (если бы все строчки были неизменяемыми и всегда создавались в куче) или провокация языком ошибок (если бы все строки были массивами
charов) были бы приемлимы?
Прошу только поменьше мне ставить минусы за высказывание своего мнения, как за начальный комментарий.
Как я понимаю, минусы или за странную форму изложения мысли, или за очень поверхностные наблюдения, поданные в категоричном тоне.
JDTamerlan
09.10.2016 13:29Спасибо! Хотел поставить Вам +1 за терпеливые разъяснения, правда кармы уже не хватает.
странную форму изложения мысли
Я думаю, каждый человек имеет право излагать мысли в удобной ему форме. Тем более, если это никак не вредит окружающим.
за очень поверхностные наблюдения, поданные в категоричном тоне
Наблюдения поверхностные — «первое впечатление», ведь я уделил языку около 2 часов. На счет категоричности тона мало согласен, основной фразой была: «впечатление осталось малоприятное».
Вообще, мне кажется, если ставить -1, то лучше описать причину. Какое малооптимальное решение было принято с моей стороны?
1) не надо делиться своим мнением и опытом
2) нужно изучить тему досконально (потратить 100...1000 часов) и только потом комментировать
3) я не имею права говорить, что мне не понравилось работать с языком
DarkEld3r
10.10.2016 12:12+1Я думаю, каждый человек имеет право излагать мысли в удобной ему форме.
Всё верно, но и другие имеют право поставить минус, пусть и "не совсем объективно".
Вообще по моему опыту, если люди начинают возмущаться (пусть и справедливо) минусами, то ситуация становится только хуже. Выводы делать не возьмусь, но ситуацию с растом попробую прокомментировать.
Языком, в основном, интересуются энтузиасты и не удивительно, что отношение соответствующее (сам такой). Опять же, по своему примеру могу сказать, что тоже прошёл стадии "что за бред?" и "зачем сделано так (криво)?!". В этом плане и правда стоит подумать решение обосновано или как можно было бы сделать лучше. Или хотя бы задавать вопрос в менее провокационной форме. (:
Скажем про строки — мне после С++ странно слышать такие претензии, где только стандартных строк есть 100500 разновидностей. Да, можно сказать, что в расте местами сделано "более топорно" из-за того, что нет отдельных перегрузок и "владеющая строка" не создаётся автоматически. Но многие в языке ценят именно явность и стоит признать, что в этом есть свои преимущества.
P.S. Не минусовал, если что.
DarkEld3r
05.10.2016 12:57+1Как по мне, это скорее вкусовщина, ну и дело привычки (синдром утёнка), но давайте посмотрим повнимательнее. Вместо ключевых слов constructor/destructor в "некоторых популярных языках" используется совсем не симметричный значок
~для деструктора. new/delete мне в программировании попадалось чаще, чем new/old. Кстати, в С++ для обращения к первому и последнему элементам (например) вектора используется front/back, а не front/last и как-то я не встречал жалоб на это.
Многие приведённые пары вообще к программированию имеют опосредовательное отношение. Ну и раз уж мы говорим и "симметричности, красоте, простоте и понятности" и были упомянуты операторы инкремента/декремента, то можно вспомнить как "симметрично" выглядит перегрузка префиксной и постфиксной форм.
ozkriff
05.10.2016 07:36+3О чем думают авторы — об экономии символов кода вместо простоты и понятности?
pub fn foo(n: &mut u32) {...}
public function foo(n: reference mutable unsigned integer32bit) {...}
Пытаются найти баланс между краткостью и понятность, что бы язык не стал ни Джавой, ни APL. Ну и да, это прям сферическая вкусовищина, где объективных критериев не может быть.
ozkriff
05.10.2016 09:17+2Я попробовал несколько подходов к изучению этого языка
Пока мне самым правильным подходом кажется:
1) Бегло пролистать Книгу — http://rurust.github.io/rust_book_ru — что бы получить общее представление о языке;
2) Пробежаться по http://rustbyexample.com и пощупать там примеры;
3) Начать писать какую-то небольшую программу:
3.1) Одновременно внимательно читать главы Книги о тех кусках языка, которые прям сейчас используешь в своем коде;
3.2) Спрашивать в https://gitter.im/ruRust/general, если чего-то все равно остается непонятным;
4) Послать парочку PR в открытые проекты, что бы как следует разобраться в том, как другие люди на языке пишут.splav_asv
05.10.2016 11:42+1ИМХО можно пункты 3 и 4 проходить в любом порядке, параллельно или даже только 4 отдельно. В свое время сделал именно так и ничуть не жалею. Обычно в открытых проектах есть задачи специально для новичков.
ozkriff
05.10.2016 11:56Можно и так, но моя логика в том что кривая обучения более плавной будет, если сначала свой малюсенький проектик написать и на нем постепенно познакомиться и понять зачем нужны всякие clippy, rustfmt, cargo, travis, appveyor и т.п., чем если все это сразу на тебя обрушится комом.
splav_asv
05.10.2016 12:05+1В оправдание могу сказать, что всё это как раз best practice и лучше осознаётся именно на примере живого проекта. На коленке сходу сложно осознать язык (собственно в этом вроде бы проблема JDTamerlan ). Но да, путь с более крутой кривой обучения и вероятно большими затратами времени в неделю.
Travis и appveyor же вообще напрямую к языку не относятся, но тоже лучше на живом проекте знакомиться, если уж до этого не сталкивался с чем-то подобным.
msts2017
05.10.2016 12:50а как-то объясняют зачем fn нужно? оно решает какую-то задачу, при парсинге, например, или просто так?
а это вообще ад.) -> () {splav_asv
05.10.2016 12:58fn даже если не решает технической задачи — якорь для взгляда. Сразу видно, что объявляется — fn, enum, struct. Это скорее вопрос единообразия как раз.
Это не ад, а вопрос привычки. Тем более так всё равно никто не пишет, а пишут
) -> {msts2017
05.10.2016 13:41-2не удивлюсь если где нибудь будут потребовать «канонический вид».
походу эту бессмысленную, на практике, конструкцию добавили для порядку, так как fn, назвали-бы кусок кода — method (mhd хехе), или еще как, без уточнения возвращает этот кусок кода не именованный параметр или нет, и не надо было захламлять язык.
по мне так зря, fn ничего не дает, пустая трата ресурсов, я как паскалист даже не вижу в коде function\procedure, определяю что метод является функцией смотря на возвращаемый тип, потому что на практике надо знать не просто что это функция а этот самый тип.
такое впечатления что Rust это C над которым поглумились паскалисты.ozkriff
05.10.2016 14:30+1Я несколько раз прочитал, но сомневаюсь четко что понял мысль.
Не нравится что из:
1) ключевое слово
fnперед объявлением функции?
2) стрелка перед возвращаемым значением функции?
3) использование пустого кортежа()в качестве заменыvoid/none/nil?
В любом случае, эта вкусовщина точно так важна? Далеко не самая интересная особенность языка же.
msts2017
05.10.2016 14:42-1Там несколько мыслей:
1) вероятность требования указывать «пустой кортеж ()» в угоду канонического вида
2) бессмысленный «пустой кортеж ()» как дань за использование ключевого слова fn
3) fn ненужно — все равно на него не обращаешь внимания на примере паскаля
4) Rust это C над которым поглумились паскалистыDarkEld3r
05.10.2016 15:11+31) Кто это может потребовать и зачем? С таким же успехом можно предположить, что у вас на паскеле потребуют (работодатель, заказчик, не важно) именовать функции строго тремя символами. Вероятность примерно одинакова.
2) А мне наоборот нравится единообразие. Вместо того чтобы вводить исключение "функция не возвращающая значение" (или процедура) используется общий механизм.
3) Так может определимся что именно не нужно? Или()илиfn(и замена для пустого возвращаемого значения). В любом случае, что мешает в расте точно так же "смотреть на возвращаемый тип"?
BlessMaster
05.10.2016 18:14+3«не обращаешь внимания» ? «не нужно»
Функция ровно в том же виде может объявляться локально рядом (перед, после) с простыми вызовами. И тут уже имеет значение, что имелось в виду — то ли функция объявляется, то ли она вызывается.
Машинный парсер можно под самые экзотические случаи придумать. Но человеку будет много легче опираться на ключевые слова с подсветкой синтаксиса.
Пустой кортеж не бессмысленен, а означает ровно то, что задумано — пустое значение. То, что на него сделали «сахар» в виде необязательности указания, так даже и хорошо, никто пока обязательного указания не требовал. Опасаться подобного ничем не лучше, чем ходить в шапочке из фольги «а вдруг инопланетяне нас зомбируют?»
msts2017
05.10.2016 14:47> В любом случае, эта вкусовщина точно так важна?
языки стремятся к единому виду, остается обсуждать только вкусовщину, да когда добавят ту или иную идею.DarkEld3r
05.10.2016 15:00+2языки стремятся к единому виду,
Не похоже, чтобы скажем Haskell, Racket и Rust к единому виду стремились. В мейнстриме, конечно, всё немного не так, но это и не удивительно.
ozkriff
Кто-нибудь workspace'ы пощупал уже, как оно на деле? :)