Subject: Re: [boost] Noexcept
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-06-13 07:13:41
2017-06-13 7:54 GMT+02:00 Vicente J. Botet Escriba via Boost <
> Le 13/06/2017 Ã 01:01, Niall Douglas via Boost a Ã©crit :
>> 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.
>> AFAIK , the proposed library and Swift error handling mechanism are
> very close. Swift has alternatively also used Result<T,E> as we could have
> The main difference I see is that one is library based and the other
> language based.
> In Swift you signal that a function can throw adding throws() to the
> signature. Swift has builtin optionals and adding throw is almost like
> declaring it to return T? (optional<T>.
> You cannot call this function without using try, try! or try?
> IIUC, with Noexcept, you cannot require this as it is a library. However
> when the user uses try_ it is able to control whether the call succeeds or
> In order to force it, the closer is to use a return type that tell you
> that there could be errors, as return_<T>.
> I will say that if Noexcept required this return_<T> type, it will be like
> outcome<T>, except that the error is transported using TLS instead of using
> the stack (please let me know if I'm wrong)
> However if Noexcept doesn't require a return_<T> then it is much difficult
> to force the use of the try functions. But it works yet.
> I see advantages in this approach and I don't know which one is more
> efficient in the success and failure cases. Some measures will be more than
> I'll rename Noexcept to ErrorTLS
> In summary,
> do we want an error handling mechanism in C++ based on Swift error
> handling ;-) ? Do we want a library that emulates it as Boost.Noexcept in
> do we want a monadic error handling in C++ as Result<T,E> in Boost?
> do we want both in Boost?
> I believe both merit to be tried
I agree with everything here. You have probably put it better than me.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk