I find it strange that this design forces you to use a single exception type, std::error, for everything you want to throw with the new mechanism. Even assumin

I find it strange that this design forces you to use a single exception type, std::error, for everything you want to throw with the new mechanism. Even assuming it makes sense to use a single exception type throughout a given codebase, as opposed to using more specific per-function error types (which admittedly has drawbacks, as mentioned in the paper), I should still be able to define my own single type rather than using the STL's implementation. Also, the idiom `throws(throws(foo))` feels like janky syntax. To explain, for anyone who hasn't bothered to read the proposal: you can use use `throws` in two different places with different meanings. Tacked onto a function declaration, `throws(COND)` means the function can throw depending on the value of COND, which should evaluate to a value of type `enum except_t`: one of no_except, static_except, or dynamic_except. But as an expression, `throws(EXPR)` does the reverse: it evaluates to an `enum except_t` representing whether/how evaluating `EXPR` can throw. So: template<typename Func> void foo(Func func) throws(throws(func())) means that calling `foo(func)` can throw iff `func()` can throw. It makes sense, at some level… I just think it looks janky.