Re: [boost] Noexcept

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