Re: [boost] [outcome] Second high level summary of review feedback accepted so far

Subject: Re: [boost] [outcome] Second high level summary of review feedback accepted so far
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-30 21:02:40

Le 30/05/2017 à 19:24, Niall Douglas via Boost a écrit :
> On 30/05/2017 17:11, Peter Dimov via Boost wrote:
>> Niall Douglas wrote:
>>> 1. I have been persuaded to use longer more appropriate naming for
>>> result<T> and outcome<T>, so now the typedefed varieties with implicit
>>> conversions to their empty-capable form indicated by "=>" are:
>>>
>>> - static_checked_outcome<T> => static_checked_optional_outcome<T>
>>>    static_checked_result<T>  => static_checked_optional_result<T>
>> ...
>>> - runtime_checked_outcome<T> => runtime_checked_optional_outcome<T>
>>>    runtime_checked_result<T>  => runtime_checked_optional_result<T>
>> ...
>>> Nobody is proposing that end users actually type out the full name
>>> each and every time they use them, and the documentation will make
>>> that clear.
>> As I already said, for me this takes away the whole point of the
>> library, which is to provide STANDARD result types which people use in
>> their public APIs.
> This is not and never has been the whole point of the proposed library.
>
> Do you accept that the static checked and runtime checked varieties are
> orthogonal user bases? There is a camp of users who strongly prefer no
> runtime overhead and static checking. There is also a camp of users who
> strongly prefer no UB possible in an uncertainty returning object.
>
> I can see a point to both camps. Neither is obviously wrong. So seeing
> as Outcome's **actual** primary goal is to provide a lightweight
> universal error handling system which eases integration of arbitrary
> third party libraries each with their own preferred choice of error
> handling strategy, the choice to provide both options with zero cost
> conversion and interoperation is the obvious one to me.
But a class can have both observer functions: narrow and wide . Why do 
we need two classes?
>
> That's the whole point and vision of Outcome. The design of the one true
> result type for C++ is exclusively on Vicente and WG21 LEWG to come up
> with. Outcome will support whatever they decide.
I don't understand why you say that.
>
> I appreciate that isn't what you want for Outcome Peter. You want a
> standard result type here and now. But that's Vicente's turf, best argue
> for that there. Outcome is here to grease the wheels between differences
> in design choice, not to declare any one right way. WG21 are better
> suited to do that.
>
I believe Peter want a Result type independently of what the standard 
will provide one day, and he wants it now and not in 2020. Maybe this 
Result type could one day a candidate for the standard. Could you 
confirm, Peter?

Vicente