Re: [boost] Noexcept

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 <
boost_at_[hidden]>:

> 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

I agree with everything here. You have probably put it better than me.

Regards,
&rzej;