Boost logo

Boost :

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


Le 13/06/2017 à 14:43, Niall Douglas via Boost a écrit :
> 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.

Not exactly. I will say it returns T? implicitly. This forces you to use
try.
>
>> 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.

What do you mean?
> 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.

The function return type should not store E, so optional T seams closer.
But I'm not an expert in Swift. I have just discovered it very recently.
I like the protocol (traits) and extension (traits extensions) mechanism ;)
>
>> 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.

What do you mean?
>
>> 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.

I'm not aware of the performances of TLS, but I would expect that if
there is a malloc hidden, we will need it only once.

If this was integrated in the language, I would expect the compiler
could reserve some efficient storage for the possible error (SBO).
>
>> 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.

It seems that it adds some value in Swift ;-)
>
> 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.

Swift exception model could complement the one in C++. It provides
everything we are locking for when we don't want to use C++ exceptions.
>
>> 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.

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

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

The two approaches are not incompatible. the variant is only the
representation. The monadic interface is applicable to several
representations.
>
> All three kinds ought to be submitted to Boost in my opinion. They cover
> three separate, though overlapping, use cases.
>
I don't plan to submit a monadic interface in Boost, at least not yet.
And if I do it one day, it will be independent of expected. In addition
we have already monadic interface with Boost.Hana. All what we need is
to adapt the concrete types.

Just a last comment, Swift try is not the same as Haskell do-notation
nor the proposed *monadic* coroutine TS await. Swift try is applicable
to PossiblyValued types not to Monadic types.

Vicente


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk