Loyd
Если люди часто ошибаются и вместо write_all используют write это говорит о чём?
Loyd
О том, что названы функции неверно и write_all должен был быть write. А write каким-то write_chunked
Αλεχ
или разрабы rustc это лохи
Αλεχ
которые не знают раста
Αλεχ
и не понимают разницы?)
Αλεχ
что ж тогда про остальных говорить
Денис
что ж тогда про остальных говорить
про них ничего не надо говорить, но вот им надо говорить "юзайте клиппи"
Денис
и да, независимо от размеров ума, линтер всё равно нужен
Денис
ума/понимания/опыта
Loyd
Да. Мы сделали местами корявый API, поэтому нужен чекер распространённых ошибок
Αλεχ
про них ничего не надо говорить, но вот им надо говорить "юзайте клиппи"
это мне напоминает аргументы С++
Αλεχ
"НИКТО ТАК НЕ ПИШЕТ"
Αλεχ
"ЭТО НЕПРАВИЛЬНЫЕ РАЗРАБОТЧИКИ"
Αλεχ
"НОРМАЛЬНЫМ ЛЮДЯМ БОРРОУЧЕКЕР ТОЛЬКО МЕШАЕТ"
Денис
началось
Loyd
Ну, борроучекер тоже мог быть линтером
Vladimir
Ну блин, нельзя делать всё идеально с первого раза
Loyd
Это правда, тут никто не спорит
Vladimir
Вот во время эпох можно
Αλεχ
ну так новая эпоха скоро
Vladimir
Но с врайтом наверное скорее нельзя
Vladimir
Будет два трейта, вряд-ли их можно в один сжать
Loyd
И будет второй похапе
Vladimir
Разве что добавить какие-то атрибуты. Трейте
Vladimir
Типа #[epoch_rename(1, "write")]
Αλεχ
Создал issue
Αλεχ
посмотрим
պլհկ
Че не так с write? Он работает ожидаемо (как в сишке)
Loyd
Че не так с write? Он работает ожидаемо (как в сишке)
Потому и второй пхп. Где-то абстракции, а где-то "как в сишке"
Loyd
Думаешь с write в си мало ошибок?)
պլհկ
Потому и второй пхп. Где-то абстракции, а где-то "как в сишке"
Все правильно, потому что язык практичный и привычность для сишников тоже ценность несет.
Loyd
Ну да, особенно типажи привычны
Αλεχ
Loyd
Ну и таких там достаточно
Loyd
Я не говорю, что апи странный или корявый в стд. Напротив, это лучшая стандартная литра, которую я видел
Loyd
Просто местами они спроектирована как логично, а не как очевиднее пользователю.
分解物質
Loyd
Ну, окей, interruptible
Αλεχ
согласен
Αλεχ
принцип наименьшего удивления не выполнен
分解物質
Ну, окей, interruptible
было бы прикольно потому что одновременно с этим std никак не поддерживает unix сигналы
Vladimir
Ну хз ok_or по-моему адекватный метод
Αλεχ
но не набирают его
Αλεχ
знаешь почему?
Αλεχ
потому что писать дольше
Vladimir
Да нет, в 90 случаев люди хотят просто ошибку из опшина получить, и не парятся за миллисекундными оптимизациями
Vladimir
Пойду поставлю тебе палец в низ в ишью
Loyd
Да нет, в 90 случаев люди хотят просто ошибку из опшина получить, и не парятся за миллисекундными оптимизациями
Как раз кейс для else "kek.ok_or_else(Error::into)"
Vladimir
Эмм
Vladimir
Ошибку откуда брать?
Loyd
Если просто оборачиваешь, то так. Можно в конкретный кайнд: ErrorKind::into
Loyd
Как будто впервые видите error chain
Vladimir
Впервые вижу статик метод в лямбде без аргументов
Vladimir
Статик метод into
Loyd
Это как раз неудивительно. А вот когда я узнал, что туда "struct Kek(a)" запихнуть можно: map(Kek)...
Ilya
Впервые вижу статик метод в лямбде без аргументов
ты меня расстраиваешь. Если попробуешь по другому - clippy заругается
Loyd
Статик метод into
Ну, от кейса зависит. Если с нуля создавать, то new, если оборачивать или конвертить, то into
Loyd
Я, кстати, нигде описание фичи с struct Kek выше не видел
Loyd
Ну, что оно там FN реализует тоже
Loyd
Но работает
Αλεχ
зачем тебе ДВА метода там, где нужен один?
Vladimir
Клиппи ругается на map_err/map ok_or_else тут не причем. У него нету параметра в лямбде
Vladimir
зачем тебе ДВА метода там, где нужен один?
В Раст нет перегрузки, я не хочу палочки рисовать
Αλεχ
ok_or
Αλεχ
or_or_else
Αλεχ
or_or_else_when
Αλεχ
ok_or_more_underscores
Αλεχ
ok_or_yet_another_overload
Αλεχ
так лучше типа?
Vladimir
И не бугурть
Loyd
В Раст нет перегрузки, я не хочу палочки рисовать
Ну он же прав, в 99 процентах тебе else нужен