On Wed, May 1, 2013 at 5:33 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:
Le 01/05/13 18:27, TONGARI a écrit :
I didn't follow this thread closely, but have you consider an implicit
convert operator to value_type? e.g.
expected<SomeType> f();
SomeType var = f(); // throws on error
It's most intuitive to me.
We need to choose between an explicit conversion to bool and an implicit (or explict) conversion to value_type, otherwise there would be a conflict when the value_type is bool. I prefer particularly the explicit bool conversion. This is in line with the optional design. BTW, the following is not so ugly.
SomeType var = f().value(); // throws on error
Best, Vicente
Let's not use optional as the pinnacle of design just yet. optional<bool> in particular. I'm concerned about: optional<bool> ob = false; if (ob) // true, as optional is 'engaged' ... if (ob == false) // true (I think) as optional<T>==(T) is used ... so bool(ob) != (ob == true). ( Or if I misunderstand the ordering of conversion-to-bool vs operator==, or optional<bool>::operator==(bool) was explicitly disallowed, then you would have a problem with optional in generic contexts: optional<SomeType> opt = ...; if (opt == SomeType(val)) ... does this behave differently when SomeType == bool vs SomeType == int? ) I suspect both optional<bool> and expected<bool> will be somewhat common uses (considering the number of tri-bool classes in existence), so I think this is a real problem that we need to resolve. (And I expect to write up something after BoostCon/C++Now) Tony