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