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
Le 31/05/2017 à 01:14, Gavin Lambert via Boost a écrit : 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