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: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-05-30 23:14:11

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

>> 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 without that, it's still possible with:
>>
>>   if (r.has_error()) { (void) r.value(); /* will throw */ }
> r.value(); // ;-)

Your point being?

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

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