Re: [boost] Noexcept

Subject: Re: [boost] Noexcept
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-13 12:43:03

On 13/06/2017 06:54, Vicente J. Botet Escriba wrote:
> Le 13/06/2017 à 01:01, Niall Douglas via Boost a écrit :
>> 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.

Syntax wise I can see what you mean. But in terms of ABI implementation,
Swift implements under the bonnet direct returns of a Result<T, E>
equivalent.

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

That is one way of looking at it. I'd suggest a more accurate way is
that all functions in Swift are noexcept. Adding "throws" is similar to
adding "noexcept(false)".

Furthermore, Swift doesn't actually implement exception throwing. Yet
another interpretation of "throws" could be "use a hidden Result<T, E>
to return from this function". This, in terms of ABI, is the most
accurate description, much more accurate than it returning optionals.

> 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)

The only remaining difference is the fragmented API using that TLS.

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

SG14 folk would reject any mandatory use of TLS as its performance is
not bounded on some platforms (hidden malloc).

Furthermore, at least on Windows both static and dynamic TLS is a
limited resource, one can run out of TLS slots easily in large programs
as there is a hard limit for the entire process. Library code should
always avoid using TLS where possible, let the end user supply TLS to it
instead.

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

I feel any design resembling C++ exceptions adds no value.

A design *complementing* C++ exceptions with a significantly different
design makes much more sense, especially as you can then use both C++
exceptions AND your design together.

>     do we want a monadic error handling in C++ as Result<T,E> in Boost?

I've been getting quite a bit of private mail from SG14 folk regarding
the Outcome review, specifically its rejection. As I said just earlier
today to one such:

"It may not have been obvious that the review arrived at three different
designs, so a flexible variant kind, a super-simple hard coded kind, and
a monadic kind. Peter Dimov is taking the variant kind to the Toronto
meeting I believe. I'm currently refactoring Outcome to implement the
super-simple kind which will be the most obviously suited for SG14
unless you like long build times. The monadic kind I suspect Vicente
will end up driving forwards, he and Peter need to disentangle the
variant kind from the monadic kind first."

All three kinds ought to be submitted to Boost in my opinion. They cover
three separate, though overlapping, use cases.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/