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

Subject: Re: [boost] [outcome] High level summary of review feedback accepted so far
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-30 23:47:09

Le 31/05/2017 à 01:14, Gavin Lambert via Boost a écrit :
> On 31/05/2017 03:39, Vicente J. Botet Escriba wrote:
>> Le 30/05/2017 à 09:27, Gavin Lambert a écrit :
>>> I think my suggestions aren't quite identical (in particular I think 
>>> empty is handled differently in some cases).  But they're close.
>> I don't want to have anything that sometimes is success and sometimes 
>> is failure.
>
> That's unavoidable for an empty state.  It's like a NULL in a database 
> or the none_t state in an optional -- it's up to whoever uses it to 
> decide "the value is missing, and that's bad because it should have 
> had one" or "the value is missing but that's ok, it doesn't have to 
> have one".
When I define functor::map/transform or monad::bind/chain, I need to 
know what is the value_type if the functor or the monad. If empty is 
part of the success alternatives it is part of the value_type. If 
success is part of the failure, it isn't part of the value_type.
If we don't define if it is a success or a failure we are unable to 
define these functions.
>
>>> In this context I'm describing behaviour absent of any judgement on 
>>> what the things are actually called.  Though FWIW both names are a 
>>> little suspect since you'd expect make_error_code to actually return 
>>> a std::error_code. 
>> And it will.
>>
>> error-code ec = r.make_error_code();
>
> What?  No, that's not what I was talking about at all.  That's just 
> silly.
But it was my that was talking about that and you didn't understood.
This is exactly what the function is doing. Building an error_code from 
an outcome or a result.

>
>>> But without that, it's still possible with:
>>>
>>>   if (r.has_error()) { (void) r.value(); /* will throw */ }
>> r.value(); // ;-)
>
> Your point being?
It is the same. No need to check as value() do it already.
>
>>> I meant literally return nullptr (exception_ptr is a NullablePointer 
>>> so it's implicitly constructible from nullptr_t), but yes, it's 
>>> basically the same thing, and the same as a default-constructed 
>>> exception_ptr.
>> I know. I wanted to state that your are returning something that 
>> could already be stored in a exception_ptr, and so the ambiguity 
>> starts. I believe that outcome should store not_null_exception_ptr 
>> instead of exception_ptr. not_null_exception_ptr is a thin class 
>> around exception_ptr that doesn't provide default constructor.
>
> That's even worse.
Why this is worse? We use the type system to prevent from user error.
>
>>> What does this mean?  I'm not sure how it applies here as we're 
>>> talking about methods with different names.
>> You have error() functions for outcome, result and expected. Each one 
>> doing one different thing.
>
> No, each one returns an error_code.  They do exactly the same thing in 
> all cases.  (Except perhaps expected, but that's because it's aiming 
> to follow a standard that might mandate different behaviour.)
No, some returns the stored error code and others can calculate one that 
doesn't correspond to the error that was transported.
Not all the functions that return an error_code must be named equal. A 
function must convey the intent.

Best,
Vicente