> Одна из самых известных проблем, ради которой какие только костыли ни придумывали
> — и "сравнение наоборот" (`2 == x` вместо `x == 2`),Вообще-то...
1) Проблема в том что сравнение было похоже на присвоение и очевидное типо вело к факапу. На момент десигна сей такой статистики не было и это еще можно понять. А потом, вот, зная типовость граблины заворкэраундили. Сколько такого в хрусте мы узнаем... потом.
2) Эта проблема в хрусте пролечена скорее уж кейвордом let, явно сделанным из подобных соображений.
3) Паскалисты делали это лучше своим :=, меньше кноп жать (2 vs 4). Просер вдвое паскалю, вчетверо сям.
4) Обругать другой яп так себе аргумент за стройность яп... :)
> и дополнительные скобки и чего только не придумывали. А всё что
> нужно — чтобы присваивание не возвращало значения.
Когда 2 = x, это ошибка, ибо константе пытаются что-то присвоить, совершенно невалидно. Но к вон тому случаю относится достаточно косвенно.
> Потому что `(10, 20)` — это и есть тупл.
В моем примере это лишь визуальное выделение, return 10, 20; ничем не хуже. Туплы все же какая-то отдельная сущность и если цель вернуть пару параметров без заморочек, выглядит каким-то оверкилом. А для наворотов и так struct были. В чем их пойнт вообще?
> Поэтому `-> (i32, i16)`.
Ну да, однако декларим вход мы все же несколько иначе и получается как-то кособоко.
> Но при вызове функции эти имена теряются, нельзя позвать `area(width: 1, height: 2)`.
Да и хрен с ним, имхо. Если кто ну вот реально именно это хотел (параметров дофига?), ему, наверное, все же struct'ы хотелось на самом деле.
> С возвращаемым значением наоборот — при вызове можно поименовать компоненты
> тупла: `let (width, height) = function();`, а в сигнатуре функции они безимянные.
И получается, блин, опять не симметрично.
> Автореференс делается в одной, строго оговорённой ситуации. Есть один реальный кейс, где
> это реально выливается в неприятную штуку, но тут просто нет решения
> лучше, нет альтернативы.
Это еще в принципе хрен с ним, всего не предусмотришь. Мое опасение здесь что когда в 1 случае автоматика есть а в другом нет, это может привести к багам когда кодер это пробакланит.
> Смысл в том, что это не учебник программирования.
Вообще-то это именно "учебник программирования на Rust" судя по виду.
> Ну и в чём проблема-то?
На самом деле - в стандартах сей и как они написаны. Бывает так что люди срезают угол, экономя себе силы там, где это делать было вообще совсем нельзя. Это именно тот случай.
> Они даже близко не стоят по степени готовности.
Says who? Адепт яп который сабж может чуть ли не только в ночнушках? :)
> Без зависимых типов это всё паллиатив, мёртвому припарка. Но в Rust такое
> можно сделать, без проблем. Только ерунда это.
Это не ерунда, это какие-то азы контрактов, чтоли, без полномасштабного залета на это. Вы правильно поняли, все хотят и рыбку съесть и косточкой не подавиться.
> Непонятно что с этим ворнингом дальше делать.
1) Там где это реально важно (safety-critical, security, reliability) и стандарты кодинга строгие, -Werror.
2) Остальным популярно рассказать фу такими быть, типа как с unsafe. Если уж кто воткнул подобие контракта то наверное имел в виду что это должно быть так.
> Только затыкать, но тогда это некорректный ворнинг получается, такому ворнингу
> в компиляторе не место, он как минимум в линтере должен быть,
Если так рассуждать, warning'ам вообще в компиляторе не место. Некоторые разделяют эту точку зрения и как минимум в сях и плюсах практикуют -Wall -Werror. Что так то очень на пользу качеству кода и отлову левых ситуаций.
> статическом анализаторе. Но полноценный статический анализатор и без явного типа-диапазона
> может провести доказательство, что в нужном месте паника не возникает.
Вот это ну не факт. Если я моим кодом генеряю вход - может быть. А если я это с ADC прочел? Ну, докажи что он мне может дать и не может. И вот в этом случае было бы айс получить варнинг или еррор, поскольку кодер, очевидно, облажался.
> Я не знаю кем такое предполагается. Учебник — это совсем другая книга,
> другой жанр. Например, не может быть учебника без задач.
В принципе они могли бы добавить и это, кмк похрустеть немного мозгом их аудитории было бы полезно :)
> Не могу тут ничего сказать. Не знаю. Но, например, монотонное время в
> наносекундах в u64 не влезает.
Могу себе представить что будет если кто hi-res время в u128 начнет безбашенно считать. Там у линуксоидов и так прикол был что на часы зырить довольно дорогая операция, а если ее еще этим обвесить... :)))
> Так, в линуксах `timespec` состоит из 64-битных секунд и 32-битных наносекунд,
> так что если пытаться упаковать это в одно число, то нужно u128.
Технически вон то занимает 96 битов в памяти. Это меньше. Переполнение оных происходить не обязано. А u128 это не только 2 64-бит регистра но и совершенно точно мастхэв кода который их переполнение ворочает. Это может и спасет от каких-то багов но может урыть перфоманс.
> Но это, конечно, слабый аргумент.
Ну хоть какой-то, я и на это не рассчитывал :)
