On 31/05/2017 11:47, Vicente J. Botet Escriba wrote:
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 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.
Why do we care about monads?
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.
Well, ok. That's basically what I said in my followup post. It was a contrived example constructed to be similar to the one that preceded it (thereby explaining why it is not necessary to have exception() return an exception in any but the actually-transporting-an-exception case).
Why this is worse? We use the type system to prevent from user error.
Having no exception is not an error. Asking for the exception is also not an error, because the exception can represent a state that means "I don't have one". This does require returning the exception_ptr by value. Is that what you're really objecting to? Or are you just too wedded to the semantics of variant? Like I said in the other thread, while I agree that the internal storage can be formed from a variant, logically the behaviour should not be that of a variant. Otherwise you'd just use a variant.
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.
They return an error_code that represents the state of the object. This
is either the actual transported error_code, or an error_code that means
"success", "an exception occurred", or "no value present". This does
not seem weird in any way to me.
Note that expected