Boost logo

Boost :

Subject: Re: [boost] Noexcept
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-06-13 05:54:13

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 [1], the proposed library and Swift error handling mechanism are
very close. Swift has alternatively also used Result<T,E> as we could
have expected<T,E>.

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 fails.

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 welcome.

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 Boost?

     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.


P.S. I've not read the full documentation yet, but this seams promising.


Boost list run by bdawes at, gregod at, cpdaniel at, john at