Open deiuch opened 3 years ago
Это прикольно и легко реализуемо в случае, если там идёт раскрытие вызовов на 1, а не до самого низа.
Если раскрытие подразумевается до самого низа, то будет сложно...
Это прикольно и легко реализуемо в случае, если там идёт раскрытие вызовов на 1, а не до самого низа.
Если раскрытие подразумевается до самого низа, то будет сложно...
Да, задумка подразумевает только просмотр сигнатур вызываемых функций без прохода вглубь, конечно :) Только там, где пользователь сам попросил компилятор просчитать возможность исключений.
Очень надо прям уже сейчас. Для своей реализации Variant прям очень нужно (ну или для тех кусков кода, где вызываются методы родителя, который package) Т.е. что-то такое:
template <typename... Types>
class Derived : Base<Types>... {
template <typename T>
void test(T&& value) noexcept(auto) {
return (::Base<T, Types>::test(std::forward<T>(value)) || ...);
}
};
В некоторых шаблонных функциях мы для полноты картины можем написать в
noexcept(...)
содержимое самой функции по сути. Это вызывает бессмысленное дублирование кода. При этом компилятор, по спецификациямnoexcept
вызываемых из этой функций вполне может сам вычислить, точно ли функция не будет выбрасывать исключений, или это потенциально возможно. Хочется научиться перекладывать эту ответственность на компилятор путём внедрения какого-то дополнения кnoexcept
-спецификации.Пример предлагаемого синтаксиса (предмет для дискуссии):
void foo() noexcept(auto) {}
Данная возможность позволит в простых случаях не дублировать код функции внутри
noexcept
, и при этом активнее пропагировать эту информацию без дополнительных усилий по проверке сигнатур вызываемых функций. Плюс это упростит использованиеnoexcept
в шаблонах функций, где многие типы или сигнатуры не будут известны до момента инстанцирования.Также можно будет по этой причине всё же ввести
noexcept
для стандартных контейнеров, но который будет определяться деталями имплементации метода стандартного контейнера (к примеру, который может начать бросать исключения в дебажной сборке), и о такомnoexcept
нужно будет меньше беспокоиться далее в использующем его коде.Обратной стороной медали будет замедление времени компиляции. Поэтому можно ограничивать использование этого спецификатора в code style на каких-то базовых случаях (для уменьшения дублирования кода, к примеру).