Still, I fail to see how Noexcept differs from Outcome in this aspect. Semantically the only difference is that Noexcept doesn't force users to use a special template in return types, but that's a good thing. If it's preferable, they can still use a special template, and if they do, it's trivial to design because it doesn't have to transport errors -- Noexcept takes care of that for you.
You *want* APIs to clearly indicate their failure contract. Relying on TLS trickery hides control flow paths. And if people fail to write the check, errors get lost or pop out in the wrong locations. Forcing a wrapper type to be used also allows [[nodiscard]] to be leveraged, and in the future static analysis to be applied. Neither works with your scheme, which is why I rejected it very early on. Finally, Rust and Swift have adopted a Result<T, E> model. It is generally viewed as a good design choice for its problem domain. Varying significantly from what the other system languages are doing needs to have very strong rationale. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/