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