@rustlang_ru - страница 1118

Loyd

Всё правильно он делает в данном месте

Loo

?

Loyd

Я пояснил выше, что это часть контракта

Loyd

Result возвращать нелогично — это ошибка программиста, что он допустил нарушение контракта

Loo

Result возвращать нелогично — это ошибка программиста, что он допустил нарушение контракта

Loo

Вот это контракты

Loyd

Ну, он не описал в документации — это минус, да

Loyd

Но это не отменяет того факта, что то, что программист захотел отрисовать прямую из одной/нуля точек — ошибка программиста

Loyd

Ну блин, ты меня троллируешь что ли? Такой мозг как ты и не знает разницы между coding errors и operational errors?

Loo

Да не, если бы в доке было описано, в разделе Panic, вопросов бы не было

Loyd

Ну это да.

Loyd

Можно прямо на гитхабе поправить и пр сделать )

Loyd

Минутное же дело

Loo

Да, надо сделать

Мерль

А что не так-то?

Можно было бы просто сделать три аргумента: первые две точки и опциональный список остальных И обойтись без runtime паник

Loyd

Неудобный апи жутко. Ты полигон хранишь нормально, массивом. Как бы type Pol = Vec<...>, а тут придётся распаковывать и слайс брать

Мерль

Неудобный апи жутко. Ты полигон хранишь нормально, массивом. Как бы type Pol = Vec<...>, а тут придётся распаковывать и слайс брать

Уж как по мне лучше чуть более кривой апи, чем очередная рантайм ошибка🤔

Loyd

Это не "очередная рантайм ошибка"

Loyd

Есть чёткое разделение между операциональными ошибками и ошибками программиста

Loyd

В том же std дохрена assert-ов в публичном апи

Loyd

Там различие понимают и это хорошо

Loyd

Без этого апи становится раздутым и непонятно зачем усложнённым

Tuntz

Result возвращать нелогично — это ошибка программиста, что он допустил нарушение контракта

в приличных домах такие контракты описывают через систему типов

Loyd

Без оверхеда с преобразованием массива в свой тип — вряд ли

Loyd

Скорее в приличных домах с верификацией предусловие тут было бы

Tuntz

struct PolylineSource { inner: &[Point2], }, а конструктор проверяет размер и возвращает Result

Tuntz

особо не пахнет оверхедом

Loyd

Ну, во-первых, ты лайфтайм потерял и с этим у пользователей будет много счастья

Loyd

Во-вторых, это не отличается от того, чтобы из функции вернуть result

Tuntz

Ну, во-первых, ты лайфтайм потерял и с этим у пользователей будет много счастья

ну не так уж и много, в крайнем случае можно и вектор держать

Tuntz

но в любом случае ассерт для публичных контрактов - ущербность в стиле Си

Loyd

Ну, расскажи это разработчикам std

分解物質

но в любом случае ассерт для публичных контрактов - ущербность в стиле Си

分解物質

Tuntz

линк в студию

分解物質

https://booksbyus.gitbooks.io/scalable-c/content/chapter2.html

Vlad

ТИХНАЛОГИИ

Євгеній 😌

ТИХНАЛОГИИ

йокарный бабай

Tuntz

ТИХНАЛОГИИ

раст какой-то ненастоящий системный язык

Tuntz

даже мозг потрахать стрингами - и то не дают

Vlad

даже мозг потрахать стрингами - и то не дают

Ну там еще CString и OSString

Маjко

даже мозг потрахать стрингами - и то не дают

Ну их много разных

Alexander

Использование error-chain неизбежно?

Маjко

Почему ты хочешь его избежать?

Маjко

Есть failure

Маjко

Ну можно и руками, канеш

Маjко

Но вряд-ли ты хочешь

Alexander

Я хотел написать простую функцию которая из строки парсит несколько чисел - пришлось делать свой enum, и потом ещё заворачивать все возвраты через map_err, что выглядело не особо.

Alexander

Не или для всего писать преобразование from, что тоже добавляем много объема, но просто за функцией.

Alexander

В общем ничего чтоб нормально выглядело с ходу не получилось, и даже в официальной главе по error-handling оно не лучше.