Сообщение Re[20]: Result objects - все-таки победили Exceptions? от 14.01.2025 18:51
Изменено 14.01.2025 19:26 T4r4sB
Re[20]: Result objects - все-таки победили Exceptions?
S>Не вижу проблемы, если указание типов опционально. То есть хочешь — и всё едет. Не хочешь — пишешь явно "здесь должно быть вот так", и дальше этой строчки изменения не поползут.
Я разрабатывал язык в котором по умолчанию любая функция шаблонная, которая по контексту определяет какие у неё параметры, сколько их и что она возвращает. Так вот это полный треш когда изменение в одной функции по цепочке приводило к тому, что компилятор что-то своё додумал в другом файле проекта и по итогу в лучшем случае ошибка компиляции, в худшем просто хрень выводится.
А ещё малозаметные проблемы когда компилятор из-за незначительных нюансов для двух наборов параметров навыводил разные перегрузки (ну типа в одном случае он решил передавать копию потому что объект временный, а в другом ссылку), и в бинарнике появляются две почти одинаковые функции. Раздувание бинарника на пустом места.
В языке был механизм явно указывать сигнатуру, который изначально был нужен лишь для экспорта функций. Но на деле оказалось что всю бизнес-логику тоже намного проще писать явными сигнатурами, потому что тогда компилятору меньше работы, и если он что-то понял не так, то он сообщает об этом максимально близко к источнику проблемы.
S>Ну, вот это и мешает писать нормально.
Как-то так. Объединять типы надо вручную
S>Одно и то же. И B|(C|A) — тоже.
А, то есть значок | грубо говоря в зависимости от операндов делает либо
— множество из двух элементов
— множество с добавленным элементов
— объединение множеств
А там может оказаться алгебраическая сумма int64_t | long long int? Или это таки один тип?
Я разрабатывал язык в котором по умолчанию любая функция шаблонная, которая по контексту определяет какие у неё параметры, сколько их и что она возвращает. Так вот это полный треш когда изменение в одной функции по цепочке приводило к тому, что компилятор что-то своё додумал в другом файле проекта и по итогу в лучшем случае ошибка компиляции, в худшем просто хрень выводится.
А ещё малозаметные проблемы когда компилятор из-за незначительных нюансов для двух наборов параметров навыводил разные перегрузки (ну типа в одном случае он решил передавать копию потому что объект временный, а в другом ссылку), и в бинарнике появляются две почти одинаковые функции. Раздувание бинарника на пустом места.
В языке был механизм явно указывать сигнатуру, который изначально был нужен лишь для экспорта функций. Но на деле оказалось что всю бизнес-логику тоже намного проще писать явными сигнатурами, потому что тогда компилятору меньше работы, и если он что-то понял не так, то он сообщает об этом максимально близко к источнику проблемы.
S>Ну, вот это и мешает писать нормально.
Как-то так. Объединять типы надо вручную
struct BarError {}
fn bar() -> Result<i32, BarError> {
Ok(10)
}
struct BazError {}
enum BarOrBazError {
BarError(BarError),
BazError(BazError),
}
impl From<BarError> for BarOrBazError {
fn from(bar_error: BarError) -> Self {
Self::BarError(bar_error)
}
}
impl From<BazError> for BarOrBazError {
fn from(baz_error: BazError) -> Self {
Self::BazError(baz_error)
}
}
fn baz() -> Result<i32, BazError> {
Ok(20)
}
fn foo() -> Result<i32, BarOrBazError> {
Ok(bar()? + baz()?)
}S>Одно и то же. И B|(C|A) — тоже.
А, то есть значок | грубо говоря в зависимости от операндов делает либо
— множество из двух элементов
— множество с добавленным элементов
— объединение множеств
А там может оказаться алгебраическая сумма int64_t | long long int? Или это таки один тип?
Re[20]: Result objects - все-таки победили Exceptions?
S>Не вижу проблемы, если указание типов опционально. То есть хочешь — и всё едет. Не хочешь — пишешь явно "здесь должно быть вот так", и дальше этой строчки изменения не поползут.
Я разрабатывал язык в котором по умолчанию любая функция шаблонная, которая по контексту определяет какие у неё параметры, сколько их и что она возвращает. Так вот это полный треш когда изменение в одной функции по цепочке приводило к тому, что компилятор что-то своё додумал в другом файле проекта и по итогу в лучшем случае ошибка компиляции, в худшем просто хрень выводится.
А ещё малозаметные проблемы когда компилятор из-за незначительных нюансов для двух наборов параметров навыводил разные перегрузки (ну типа в одном случае он решил передавать копию потому что объект временный, а в другом ссылку), и в бинарнике появляются две почти одинаковые функции. Раздувание бинарника на пустом места.
В языке был механизм явно указывать сигнатуру, который изначально был нужен лишь для экспорта функций. Но на деле оказалось что всю бизнес-логику тоже намного проще писать явными сигнатурами, потому что тогда компилятору меньше работы, и если он что-то понял не так, то он сообщает об этом максимально близко к источнику проблемы.
S>Ну, вот это и мешает писать нормально.
Как-то так. Объединять типы надо вручную
Проблема не нова
https://www.reddit.com/r/rust/comments/jwnsp4/anonymous_sum_types_for_rust_error_handling/
S>Одно и то же. И B|(C|A) — тоже.
А, то есть значок | грубо говоря в зависимости от операндов делает либо
— множество из двух элементов
— множество с добавленным элементов
— объединение множеств
А там может оказаться алгебраическая сумма int64_t | long long int? Или это таки один тип?
Я разрабатывал язык в котором по умолчанию любая функция шаблонная, которая по контексту определяет какие у неё параметры, сколько их и что она возвращает. Так вот это полный треш когда изменение в одной функции по цепочке приводило к тому, что компилятор что-то своё додумал в другом файле проекта и по итогу в лучшем случае ошибка компиляции, в худшем просто хрень выводится.
А ещё малозаметные проблемы когда компилятор из-за незначительных нюансов для двух наборов параметров навыводил разные перегрузки (ну типа в одном случае он решил передавать копию потому что объект временный, а в другом ссылку), и в бинарнике появляются две почти одинаковые функции. Раздувание бинарника на пустом места.
В языке был механизм явно указывать сигнатуру, который изначально был нужен лишь для экспорта функций. Но на деле оказалось что всю бизнес-логику тоже намного проще писать явными сигнатурами, потому что тогда компилятору меньше работы, и если он что-то понял не так, то он сообщает об этом максимально близко к источнику проблемы.
S>Ну, вот это и мешает писать нормально.
Как-то так. Объединять типы надо вручную
struct BarError {}
fn bar() -> Result<i32, BarError> {
Ok(10)
}
struct BazError {}
enum BarOrBazError {
BarError(BarError),
BazError(BazError),
}
impl From<BarError> for BarOrBazError {
fn from(bar_error: BarError) -> Self {
Self::BarError(bar_error)
}
}
impl From<BazError> for BarOrBazError {
fn from(baz_error: BazError) -> Self {
Self::BazError(baz_error)
}
}
fn baz() -> Result<i32, BazError> {
Ok(20)
}
fn foo() -> Result<i32, BarOrBazError> {
Ok(bar()? + baz()?)
}Проблема не нова
https://www.reddit.com/r/rust/comments/jwnsp4/anonymous_sum_types_for_rust_error_handling/
S>Одно и то же. И B|(C|A) — тоже.
А, то есть значок | грубо говоря в зависимости от операндов делает либо
— множество из двух элементов
— множество с добавленным элементов
— объединение множеств
А там может оказаться алгебраическая сумма int64_t | long long int? Или это таки один тип?