История изменений

чтобы он возвращал std::optional вместо киданий исключения (привет std::bad_cast, std::bad_weak_ptr, и.т.д.) Их разработчики зачастую забывают обрабатывать

А optional будут тупо разыменовывать, в точности так же как в расте тупо разыменовывают результат, забивая на обработку ошибок. Разница с растом только в том, что он при разыменовании рухнет, а плюсы таки-бросят исключение (шило на мыло: сразу нельзя было бросить?).

И ещё разница в том, что ловить исключения нужно в гораздо меньшем количестве мест, чем проверять результат. А именно – только в пользовательских точках входа. И забыть сложнее, и кодить не так гиморно. В вебе, например, таковая точка входа – вообще одна. Так что идея с возвратом optional – такое же говно как и раст. (Даже хуже: в случае ошибки раст хотя бы вернёт информацию об ошибке, а не тупо std::nullopt – и догадывайся как хочешь.)

// Я в курсе, что например в scala – Option много где используется. Но там и исключения много где используются. Потому что:

Вернее, так: вы на пару с kvpfs_2 генерируете какие-то свои фантазии, хотя правило, когда юзать исключения, а когда код возврата/optional/etc., тыщу лет известно и общепринято: если ошибка является частью нормального workflow т.е. бизнес-логики (например, юзер не заполнил обязательное поле) – это код возврата; если это нештатная ситуация (ошибка в программе, или например база отвалилась) – исключение. И продиктовано это правило простым соображением баланса сложности и скорости: исключения медленнее, чем код возврата, но используются сильно реже. В смысле, бросаются в рантайме сильно реже. А в исходном коде количество дурацких проверок в каждой строчке сокращается на порядки.

std::optional не даст никакого over-head’а в 95% случаев.

Да щаз.

static_assert(sizeof(std::optional<int64_t>) == 2 * sizeof(int64_t));

И даже если запихать это в packed-структуру, один сраный булев флаг будет по-прежнему занимать 8 байт (согласно выравниванию хранимого типа).

чтобы он возвращал std::optional вместо киданий исключения (привет std::bad_cast, std::bad_weak_ptr, и.т.д.) Их разработчики зачастую забывают обрабатывать

А optional будут тупо разыменовывать, в точности так же как в расте тупо разыменовывают результат, забивая на обработку ошибок. Разница с растом только в том, что он при разыменовании рухнет, а плюсы таки-бросят исключение (шило на мыло: сразу нельзя было бросить?).

И ещё разница в том, что ловить исключения нужно в гораздо меньшем количестве мест, чем проверять результат. И забыть сложнее, и кодить не так гиморно. Так что идея с возвратом optional – такое же говно как и раст. (Даже хуже: в случае ошибки раст хотя бы вернёт информацию об ошибке, а не тупо std::nullopt – и догадывайся как хочешь.)

// Я в курсе, что например в scala – Option много где используется. Но там и исключения много где используются. Потому что:

Вернее, так: вы на пару с kvpfs_2 генерируете какие-то свои фантазии, хотя правило, когда юзать исключения, а когда код возврата/optional/etc., тыщу лет известно и общепринято: если ошибка является частью нормального workflow т.е. бизнес-логики (например, юзер не заполнил обязательное поле) – это код возврата; если это нештатная ситуация (ошибка в программе, или например база отвалилась) – исключение. И продиктовано это правило простым соображением баланса сложности и скорости: исключения медленнее, чем код возврата, но используются сильно реже. В смысле, бросаются в рантайме сильно реже. А в исходном коде количество дурацких проверок в каждой строчке сокращается на порядки.

std::optional не даст никакого over-head’а в 95% случаев.

Да щаз.

static_assert(sizeof(std::optional<int64_t>) == 2 * sizeof(int64_t));

И даже если запихать это в packed-структуру, один сраный булев флаг будет по-прежнему занимать 8 байт (согласно выравниванию хранимого типа).

чтобы он возвращал std::optional вместо киданий исключения (привет std::bad_cast, std::bad_weak_ptr, и.т.д.) Их разработчики зачастую забывают обрабатывать

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

И ещё разница в том, что ловить исключения нужно в гораздо меньшем количестве мест, чем проверять результат. И забыть сложнее, и кодить не так гиморно. Так что идея с возвратом optional – такое же говно как и раст. (Даже хуже: в случае ошибки раст хотя бы вернёт информацию об ошибке, а не тупо std::nullopt – и догадывайся как хочешь.)

// Я в курсе, что например в scala – Option много где используется. Но там и исключения много где используются. Потому что:

Вернее, так: вы на пару с kvpfs_2 генерируете какие-то свои фантазии, хотя правило, когда юзать исключения, а когда код возврата/optional/etc., тыщу лет известно и общепринято: если ошибка является частью нормального workflow т.е. бизнес-логики (например, юзер не заполнил обязательное поле) – это код возврата; если это нештатная ситуация (ошибка в программе, или например база отвалилась) – исключение. И продиктовано это правило простым соображением баланса сложности и скорости: исключения медленнее, чем код возврата, но используются сильно реже. В смысле, бросаются в рантайме сильно реже. А в исходном коде количество дурацких проверок в каждой строчке сокращается на порядки.

std::optional не даст никакого over-head’а в 95% случаев.

Да щаз.

static_assert(sizeof(std::optional<int64_t>) == 2 * sizeof(int64_t));

И даже если запихать это в packed-структуру, один сраный булев флаг будет по-прежнему занимать 8 байт (согласно выравниванию хранимого типа).

чтобы он возвращал std::optional вместо киданий исключения (привет std::bad_cast, std::bad_weak_ptr, и.т.д.) Их разработчики зачастую забывают обрабатывать

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

И ещё разница в том, что ловить исключения нужно в гораздо меньшем количестве мест, чем проверять результат. И забыть сложнее, и кодить не так гиморно. Так что идея с возвратом optional – такое же говно как и раст. (Даже хуже: в случае ошибки раст хотя бы вернёт информацию об ошибке, а не тупо std::nullopt и догадывайся как хочешь.)

// Я в курсе, что например в scala – Option много где используется. Но там и исключения много где используются. Потому что:

Вернее, так: вы на пару с kvpfs_2 генерируете какие-то свои фантазии, хотя правило, когда юзать исключения, а когда код возврата/optional/etc., тыщу лет известно и общепринято: если ошибка является частью нормального workflow т.е. бизнес-логики (например, юзер не заполнил обязательное поле) – это код возврата; если это нештатная ситуация (ошибка в программе, или например база отвалилась) – исключение. И продиктовано это правило простым соображением баланса сложности и скорости: исключения медленнее, чем код возврата, но используются сильно реже. В смысле, бросаются в рантайме сильно реже. А в исходном коде количество дурацких проверок в каждой строчке сокращается на порядки.

std::optional не даст никакого over-head’а в 95% случаев.

Да щаз.

static_assert(sizeof(std::optional<int64_t>) == 2 * sizeof(int64_t));

И даже если запихать это в packed-структуру, один сраный булев флаг будет по-прежнему занимать 8 байт (согласно выравниванию хранимого типа).

чтобы он возвращал std::optional вместо киданий исключения (привет std::bad_cast, std::bad_weak_ptr, и.т.д.) Их разработчики зачастую забывают обрабатывать

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

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

// Я в курсе, что например в scala – Option много где используется. Но там и исключения много где используются. Потому что:

Вернее, так: вы на пару с kvpfs_2 генерируете какие-то свои фантазии, хотя правило, когда юзать исключения, а когда код возврата/optional/etc., тыщу лет известно и общепринято: если ошибка является частью нормального workflow т.е. бизнес-логики (например, юзер не заполнил обязательное поле) – это код возврата; если это нештатная ситуация (ошибка в программе, или например база отвалилась) – исключение. И продиктовано это правило простым соображением баланса сложности и скорости: исключения медленнее, чем код возврата, но используются сильно реже. В смысле, бросаются в рантайме сильно реже. А в исходном коде количество дурацких проверок в каждой строчке сокращается на порядки.

std::optional не даст никакого over-head’а в 95% случаев.

Да щаз.

static_assert(sizeof(std::optional<int64_t>) == 2 * sizeof(int64_t));

И даже если запихать это в packed-структуру, один сраный булев флаг будет по-прежнему занимать 8 байт (согласно выравниванию хранимого типа).

чтобы он возвращал std::optional вместо киданий исключения (привет std::bad_cast, std::bad_weak_ptr, и.т.д.) Их разработчики зачастую забывают обрабатывать

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

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

// Я в курсе, что например в scala – Option много где используется. Но там и исключения много где используются. Потому что:

Вернее, так: вы на пару с kvpfs_2 генерируете какие-то свои фантазии, хотя правило, когда юзать исключения, а когда код возврата/optional/etc., тыщу лет известно и общепринято: если ошибка является частью нормального workflow т.е. бизнес-логики (например, юзер не заполнил обязательное поле) – это код возврата; если это нештатная ситуация (ошибка в программе, или например база отвалилась) – исключение. И продиктовано это правило простым соображением баланса сложности и скорости: исключения медленнее, чем код возврата, но используются сильно реже.

std::optional не даст никакого over-head’а в 95% случаев.

Да щаз.

static_assert(sizeof(std::optional<int64_t>) == 2 * sizeof(int64_t));

И даже если запихать это в packed-структуру, один сраный булев флаг будет по-прежнему занимать 8 байт (согласно выравниванию хранимого типа).

чтобы он возвращал std::optional вместо киданий исключения (привет std::bad_cast, std::bad_weak_ptr, и.т.д.) Их разработчики зачастую забывают обрабатывать

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

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

// Я в курсе, что например в scala – Option много где используется. Но там и исключения много где используются. Потому что:

Вернее, так: вы на пару с kvpfs_2 генерируете какие-то свои фантазии, хотя правило, когда юзать исключения, а когда код возврата/optional/etc., тыщу лет известно и общепринято: если ошибка является частью нормального workflow т.е. бизнес-логики (например, юзер не заполнил обязательное поле) – это код возврата; если это нештатная ситуация (ошибка в программе, или например база отвалилась) – исключение. И продиктовано это правило простым соображением баланса сложности и скорости: исключения бросаются дольше, чем код возврата, но реже.

std::optional не даст никакого over-head’а в 95% случаев.

Да щаз.

static_assert(sizeof(std::optional<int64_t>) == 2 * sizeof(int64_t));

И даже если запихать это в packed-структуру, один сраный булев флаг будет по-прежнему занимать 8 байт (согласно выравниванию хранимого типа).