Альфа-версия Rust 1.0

Каков тип возвращаемого значения get? Тип аргумента and_then? Тип возвращаемого значения and_then?

Ну некий optional(из boost или std, хотя в 14ом его не взяли). and_then там нет правда, но можно сделать.

То есть надо взять Boost и допилить его руками, окей. Правда, это не совсем то, что нужно, потому что В Rust get возвращает не Option, а Result, но ладно.

Тип аргумента метода and_then - функция

Тоже не совсем то, что в Rust, но тоже ладно.

(ошибки или через optional или через исключения - как сделаем)

Если сделаете через исключения, снова неэквивалентный код.

Такая вот кучка костыликов, да.

В Rust get возвращает не Option, а Result

Ну можно сделать Result какой-нибудь. Ничего уникального тут rust не даёт. Все это реализуемо на C++ и не сильно будет уступать rust в использовании.

Такая вот кучка костыликов, да

Ничего тут костыльного нет, обычная библиотечная реализация.

В крестах обычно все же через исключения работают. Так что теперь ваша очередь показать аналог исключений в расте.

В Rust get возвращает не Option, а Result

Ну можно сделать Result какой-нибудь.

Все это реализуемо на C++ и не сильно будет уступать rust в использовании.

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

Ничего уникального тут rust не даёт.

Никто и не говорил, что Rust дает что-то уникальное _тут_. Если что, главная фишка Rust - проверяемая компилятором безопасность работы с памятью. А дженерики и ADT - вещь довольно обычная (хотя ADT в Си++ и нет).

Ничего тут костыльного нет, обычная библиотечная реализация.

Пока ты ничего не реализовал, посмотри на Boost.Variant и повтори «ничего костыльного».

В крестах обычно все же через исключения работают

В крестах обычно так же запрещение исключений в гайдлайнах.

Так что теперь ваша очередь показать аналог исключений в расте.

Зачем? Я уже много раз сказал, что их нет.

вон выше юный подован распинался о крутизне макросов.

Макросы сишные - отстой.

Сделай, реализуй, попробуй.

Зачем? Я примерно представляю себе реализацию, но не вижу особого смысла. Будет нужно - сделаю.

Если что, главная фишка Rust - проверяемая компилятором безопасность работы с памятью

Насколько я понимаю, проверяются довольно тривиальные вещи. Полезно, да, но вот стоит ли оно того?

ADT

Ты, наверное, об алгебраических типах? Просто обычно ADT - это абстрактные типы данных.

В крестах нету, да(Страуструп что-то предлагал/делал, не знаю чем дело кончилось). Иногда хотелось бы. Есть boost::variant, но там что-то сложное в ад превращается.

Сделай, реализуй, попробуй.

Зачем?

Чтобы сравнить реализации и использование. Сказать «реализуемо» легко, но бесполезно.

Полезно, да, но вот стоит ли оно того?

Это одна из вещей, которые предстоит выяснить.

Просто обычно ADT - это абстрактные типы данных.

Последние годы «обычно» именно алгебраические. Я о них.

В крестах обычно так же запрещение исключений в гайдлайнах.

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

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

Зачем? Я уже много раз сказал, что их нет.

Ну в крестах в стандартной библиотеке нет Option/Result и пр., что не мешало тебе попросить привести аналог.

Что мне делать, если мне кажется, что исключения хорошо подходят для проекта? Ведь я не смогу использовать их в rust никак?

В крестах обычно так же запрещение исключений в гайдлайнах.

Так делают только тогда
Это если мы не рассматриваем

Взаимоисключающие соблюдены.

Ну в крестах в стандартной библиотеке нет Option/Result и пр., что не мешало тебе попросить привести аналог.

Мне не помешало попросить? Это тебе пришлось на них сослаться:

anonymous> Ну некий optional(из boost или std, хотя в 14ом его не взяли). and_then там нет правда, но можно сделать

Что мне делать, если мне кажется, что исключения хорошо подходят для проекта?

Для начала тебе перестать употреблять совершенно прекрасные фразы «исключения хорошо подходят для проекта». А если не можешь писать программ без исключений - просто не используй Rust.

Взаимоисключающие соблюдены.

Нет там взаимоисключающих. Второе, это условие. Т.е. кроме особых случаев, подобные запреты не имеют смысла с точки зрения инструмента.

Мне не помешало попросить? Это тебе пришлось на них сослаться

Ты просил аналог на плюсах.

Для начала тебе перестать употреблять совершенно прекрасные фразы «исключения хорошо подходят для проекта».

А что тут не так? Это означает, например, что исключительные ситуации редки, каких-то сложных изменений в логике они не порождают, пропускать их при этом не желательно(«лучше упасть»). Вот пример набора характеристик проекта, которые могут навести на мысль о том, что исключения хороший выбор.

А если не можешь писать программ без исключений - просто не используй Rust.

Я могу. Но это не всегда удобно. Жаль, что Rust и тут меня ограничивает.

Нет там взаимоисключающих.

okay.jpg

Ты просил аналог на плюсах.

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

например, что исключительные ситуации редки, каких-то сложных изменений в логике они не порождают, пропускать их при этом не желательно(«лучше упасть»)

Во-первых, это не характеристика проекта; во-вторых, если для того, чтобы упасть, нужны исключения - вопросов больше нет.

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

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

Во-первых, это не характеристика проекта

А что это?

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

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

Я просто взял то, что наиболее похоже из готового.

Готового нет. Ты сказал «если мы возьмем Boost, допилим его как-то так, то сможем написать очень похоже на Rust».

Но ты почему-то требовал аналога

Функционального аналога. Желательно, написанного в терминах стандартной библиотеки. Хочешь написать с исключениями - валяй.

Ну или ты «должен»(условно) доказать, что механизмы раст приводят к тому, что исключения не нужны.

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

Функционального аналога. Желательно, написанного в терминах стандартной библиотеки. Хочешь написать с исключениями - валяй.

Так а зачем так писать, ведь ты даже сообщения об ошибках не пишешь в этом коде? Кому такой код нужен? Лучше покажи аналог вот этого на rust:

int data = 0;
try {
    data = argc > 1 ? stoi(argv[0]) : 100;
}
catch (std::excepion & e) {
    cout << "invalid argument: " << e.what() << endl;
}

argv[1] там, опечатался.

То, что без исключений можно обойтись

Так обойтись можно без многого. Вопрос в удобстве и целесообразности.

let n = std::os::args().get(1).and_then(|n| n.parse()).unwrap_or(100);

vs

int data = 0;
try {
    data = argc > 1 ? stoi(argv[0]) : 100;
}
catch (std::excepion & e) {
    cout << "invalid argument: " << e.what() << endl;
}

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

Разве что так.

let n = std::os::args().get(1).map(|s| s.parse().unwrap_or_else(|| {
	println!("Invalid argument {}", s);
	0
})).unwrap_or(100i);

Где вывод сообщения об ошибке в Rust?

А ошибку в C++ коде уже описали - argv[1] там. Ну и еще std::exception. В общем, опечатки.

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

Где вывод сообщения об ошибке в Rust?

Его там нет, откуда он в Си++-варианте - ХЗ.

А ошибку в C++ коде уже описали - argv[1] там. Ну и еще std::exception.

Ошибка только одна - argv[0].

В общем, опечатки.

Характерная ошибка по очевидной причине.

Его там нет, откуда он в Си++-варианте - ХЗ.

Человек тебе предложил более практичный пример. Как ты собрался в реальной жизни замалчивать ошибки - ХЗ

Ошибка только одна - argv[0].

Нет, еще excepion вместо exception

Характерная ошибка по очевидной причине.

Рискну предположить, что печатали с телефона/планшета. argv[0] и args.get(0) - не вижу тут принципиальной разницы в ошибке.

Его там нет, откуда он в Си++-варианте - ХЗ.

А ты прочти сообщение и узнаешь. Так будет аналог на Rust? Или на Rust можно писать только программы, не требующие обработки ошибок?

Человек тебе предложил более практичный пример

А у него просили функциональный аналог.

Ошибка только одна - argv[0].

Нет, еще excepion вместо exception

То, что отлавливается компилятором - не ошибка.

argv[0] и args.get(0) - не вижу тут принципиальной разницы в ошибке.

Ошибка появилась оттого, что индекс пришлось набирать 2 раза // К.О.

А у него просили функциональный аналог.

Я его и показал.

При отсутствии агрумента, n = 100. При ошибке преобразования строки в число вывести сообщение и n = 0.

А у него просили функциональный аналог.

Я его и показал.

Ты написал Си++-вариант от имени анонимуса?

Альфа-версия Rust 1.0 (комментарий)

По-моему, я ясно сказал, что говорю о Си++ варианте. То, что после этого ты написал аналог Си++-варианта на Rust, к моему разговору с анонимусом отношения не имеет.

ради пятницосрачей на ЛОРе

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

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

Судя по коду с обработкой ошибок, который тут выше показали, rust плохо с этим справляется.

Как не имеет? Тебя же попросили предоставить код, а ты все отмазываешься...

проглатывание*

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

Так что давай рассмотрим механизм обработки ошибок в rust более серьёзно. Может ли он обеспечить обязательную обработку ошибки, организацию иерархий ошибок, перехват ошибки в нужном для исправления ситуации месте и пр.?

Ошибка в индексе не из-за двух раз.

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

И да, никто не мешает написать функцию, чтоб брать один раз.

Она будет возвращать optional или бросать исключение?

Судя по коду с обработкой ошибок, который тут выше показали, rust плохо с этим справляется.

Потому что хорошей обработкой ошибки является запуск исключения, да?

Может ли он обеспечить обязательную обработку ошибки

Постарайся точно сформулировать, что такое «обязательная обработка ошибки».

организацию иерархий ошибок,

Да.

перехват ошибки в нужном для исправления ситуации месте

Что это?

и пр.?

Бгг.

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

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

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

Тебе говорят о том, что на C++ не проблема сделать так же, как в Rust(только не очень нужно), а обратное неверно. Т.е. rust многими плюсовиками рассматривается как еще один язычек, вводящий ненужные ограничения для неосиляторов. Что-то в этом есть.

Потому что хорошей обработкой ошибки является запуск исключения, да?

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

Тебе говорят о том, что на C++ не проблема сделать так же, как в Rust

Не проблема реализовать приведенный однострочник практически неотличимо от Rust, только для этого придется 1) использовать Boost 2) допилить его.

обратное неверно

Я нигде не утверждал, что Rust по всем параметрам мощнее Си++.

rust многими плюсовиками рассматривается как еще один язычек, вводящий ненужные ограничения для неосиляторов

«Within C++, there is a much smaller and cleaner language struggling to get out» (ц)

let n = std::os::args().get(1).and_then(|n| n.parse()).unwrap_or(100);

std::os::args возвращает Vec<String>. Но я что-то не вижу метода get у Vec. Можешь пояснить?

Можешь пояснить?

Думаю, через какой-то трейт цепляет. playpen не ругается - мне хватает :)

http://www.contrib.andrew.cmu.edu/~acrichto/doc/std/vec/trait.ImmutableVector...

http://doc.rust-lang.org/std/slice/trait.SliceExt.html#tymethod.get

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

Там хитрость в неявном Deref'е. Т.е, например, vec.get(1) это на самом деле (&*vec).get(1) (ну или &mut). Это удобно в языке умными указателями и с разграничением владения и заимствования, но с первого взгляда не очевидно.

Она будет возвращать optional или бросать исключение?

Да как захотим, так и будет. Тебе что надо?

Потому что хорошей обработкой ошибки является запуск исключения, да?

Потому, что на код на расте без слез не взглянешь.

Постарайся точно сформулировать, что такое «обязательная обработка ошибки».

Это значит, что её не смогут неявно «проглотить». Вот ты в своём коде никак на ошибки не реагируешь. Как ты себе это представляешь в реальном проекте?

Можешь показать пример иерархии ошибок?

Что это?

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

Она будет возвращать optional или бросать исключение?

Да как захотим, так и будет.

Вариант с возвращением optional уже приведен и обсуждн, сделаешь исключение - код раздуется на еще один try-блок.

Потому что хорошей обработкой ошибки является запуск исключения, да?

Потому, что на код на расте без слез не взглянешь.

Это не ответ.

Постарайся точно сформулировать, что такое «обязательная обработка ошибки».

Это значит, что её не смогут неявно «проглотить».

В Rust нельзя неявно «проглотить» ошибку - должен быть match на результате, в самом match должна быть ветка для ошибочного варианта.

Вот ты в своём коде никак на ошибки не реагируешь.

Это не мой код, но ошибка там игнорируется сознательно.

Можешь показать пример иерархии ошибок?

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

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

Это возможно даже в Си. Естественно, придется пробрасывать ошибку до нужного уровня.

Это не ответ.

Но ведь это правда...

но ошибка там игнорируется сознательно.

Такое редко нужно на практике. Разве нет? А код с обработкой выглядит ужасающе.

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

но ошибка там игнорируется сознательно.

Такое редко нужно на практике. Разве нет?

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

В том же Ocaml есть исключения

Ocaml не является языком системного программирования (только не надо про Mirage).

и это не мешает ничему «правильному»

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

Спокойно, в rust есть ffi к c, так что кому надо исключения — добро пожаловать в мир setjmp/longjmp.

Оно не будет по пути уничтожать Rust-объекты на стеке :(