и чем это лучше , чем "123".parse().map_err(Into::into) ?

Тем же чем ? лучше чем try!()

ну нет

try! увеличивает вложенность, а ? — нет

но

несколько символов таки экономятся

в каждой функции связанной с utf8, fs, path и т.д. таких map_err(From::from) прихожится по 2-3 на функцию писать (по штуке на кложуру и итоговый)

ну сделай пропозал, почему нет :) только я бы назвал это err_into, а не err_from, и тогда уж надо делать и ok_into, для симметричности )

в итоге код состоит не из логики а из сплошных from и map

в каждой функции связанной с utf8, fs, path и т.д. таких map_err(From::from) прихожится по 2-3 на функцию писать (по штуке на кложуру и итоговый)

а что тебе мешает сделать правильный возвращаемый тип?

если ты ВСЕГДА конвертишь результат, значит ты что-то делаешь не так, не? :)

а я так тоже делаю. bla_bla().or_bad_request()?; вообще для таких трейтов даже naming convention есть. их принято называть ResultExt, OptionExt...

Эм, потому что в одном случае Utf8Error, в другом IoResult, в третьем еще что то, а тебе нужен один тип ошибки?

Эм, потому что в одном случае Utf8Error, в другом IoResult, в третьем еще что то, а тебе нужен один тип ошибки?

не на этом этапе он тебе нужен

он тебе нужен, когда у тебя внутри может произойти много всяких ошибок

и вот тогда надо конвертить, ибо другого варианта нет

Я про это тогда и говорю

ну ок

реально, сделай крейт, который расширяет Result

как @andy128k подсказывает

мини-крейтик

пропиарь его на реддите

если народ будет активно пользоваться — можно будет задуматься и о том, чтобы в STD добавить

Причем в failure есть ResultExt но там такого метода нет

ну заведи им ишшью, там же живые люди сидят

приведи им примеры, от которых у тебя горит

ваще мне кажется, что .map(Into::into) полностью укладывается в функциональную парадигму

так что такое утверждение я бы назвал слишком толстым)

в итоге код состоит не из логики а из сплошных from и map

для std и failure возможно лишнее, тем более если try-throw введут, а крейт запилю

и назову BetterThanTryThrow

и назову BetterThanTryThrow

клиппи скажет что плохое имя

надо snake_case

bttt

щас бы роботов слушать

клиппи скажет что плохое имя

да и cargo run тожк

ну сделай пропозал, почему нет :) только я бы назвал это err_into, а не err_from, и тогда уж надо делать и ok_into, для симметричности )

осталось с названием функции определиться, err_into будет путаться с into_result и from_error от Try

што?

я думаю о fit_err, fit_error или match_err

ну, смотри сам

https://docs.rs/futures/0.1/futures/future/trait.Future.html#method.from_err

щас бы роботов слушать

щас бы не придерживаться единого стиля

ценник не помнишь? =)

ценник не помнишь? =)

2K

спасибо

мне казалось кто-то недавно сталкивался с такой проблемой? https://play.rust-lang.org/?gist=1324c1dc8d5148e4bf95ba703328ef53&version=nightly&mode=debug

а, через индекс по-моему можно обойти

https://play.rust-lang.org/?gist=2c202496299c81edd372bd40bd810fbd&version=stable&mode=debug — но это пиздец конечно

мне казалось кто-то недавно сталкивался с такой проблемой? https://play.rust-lang.org/?gist=1324c1dc8d5148e4bf95ba703328ef53&version=nightly&mode=debug

а это не через Entry делается?

у мапы есть entry, у вектора — нет

так ты же делаешь обёртку

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

в смысле?)

я бы ваще заюзал мапу, но тип не имплементит ни ord, ни hash

а, через индекс по-моему можно обойти

а на самом деле там конечно не u8?

а на самом деле там конечно не u8?

угу, там тип, который не имплементит ни ord, ни hash, только eq

unsafe можешь убрать, все равно компилятор двойную проверку границ выкинет

вот бы щас на оптимизацию понадеяться)

даже в go компилятор такое делает сейчас бы микрооптимизациями без бенчмарков в боевом окружении заниматься

то есть .get(n).unwrap() лучше, чем ансейф?

спасибо, не надо

даже в go компилятор такое делает сейчас бы микрооптимизациями без бенчмарков в боевом окружении заниматься

а как он определяет это у динамического массива?

ну т.е., как я понял, value, ok := smth.get(i)

будет всегда возвращать X, false ?

то есть .get(n).unwrap() лучше, чем ансейф?

не, ну для такого конечно никакие проверки нельзя убрать но если идёт обход в цикле или итератором, то компилятор может подхачить

да понятно, что может, и не просто может, а хачит) но если у меня есть выбор между "сделать так, чтобы наверняка" и "да rustc/llvm соптимизируют", и при этом первый вариант не требует от меня ровным счётом никаких усилий, то я выбираю его )

Слушайте народ, щас вопрос не холивара ради а из жизненной проблемы

https://github.com/rise-ui/rise-stylesheet/issues/1

(Если чо знаю описал тупо и коряво но все же)

суть в том что есть webrender builder который собирает узлы плоско в дерево

есть контекст style который делать push_stacking_context чтобы определить новый контейнер узел, и делает рисовку конкретного элемента, когда дерево вглубь заканчивается у элемента надо сделать pop_stacking_context() чтобы выйти в другой контекст отрисовки узла. И в итоге у меня проблема - за отрисовку отвечает одна структура, а закрытие контекста делается в итераторе на уровне самого rise в методе рекурсивном методе render. Хотел бы узнать моджно ли сделать это как нибудь красиво чтобы всем занимался именно Style контекст, включая закрытие области своей

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

не, ну для такого конечно никакие проверки нельзя убрать но если идёт обход в цикле или итератором, то компилятор может подхачить

типо он сравнивает, что n < len(vec) и потом берёт как unchecked?

да понятно, что может, и не просто может, а хачит) но если у меня есть выбор между "сделать так, чтобы наверняка" и "да rustc/llvm соптимизируют", и при этом первый вариант не требует от меня ровным счётом никаких усилий, то я выбираю его )

тут скорее выбирать из: — гарантированно работающий способ — микропптимизация с использованием unsafe, скостыленная даже без микробенчмарков

мне казалось кто-то недавно сталкивался с такой проблемой? https://play.rust-lang.org/?gist=1324c1dc8d5148e4bf95ba703328ef53&version=nightly&mode=debug

Все правильно, это ансейф

тут скорее выбирать из: — гарантированно работающий способ — микропптимизация с использованием unsafe, скостыленная даже без микробенчмарков

но get_unchecked это ведь тоже гарантированно рабочий способ..

Все правильно, это ансейф

что именно тут ансейф?

типо он сравнивает, что n < len(vec) и потом берёт как unchecked?

зависит от кучи всего, включая фазу луны даже не буду гадать, это нужно смотреть на ассемблер конкретного случая

зависит от кучи всего, включая фазу луны даже не буду гадать, это нужно смотреть на ассемблер конкретного случая

> зависит от кучи всего, включая фазу луны ну т.е. это такой же вопрос, что и в расте оптимизация .get()? я просто так и не понял преимущества, что то, что другое не обязательно оптимизируется а get_unchecked — однозначная конструкция, тут я согласен с @mexus

Хотя с ретурном вроде не ансейф 🤔