Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2013-05-02 10:17:43
On Wed, May 1, 2013 at 8:23 PM, Vicente J. Botet Escriba <
> Le 02/05/13 00:29, Gottlob Frege a écrit :
> 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)
> Agreed. I could try the std-proposal forum or c++std-lib-ext_at_[hidden] if
> you don't mind.
You of course could, but I think std-proposal and the committee has
probably had enough of optional for a while. I think the next best step is
a paper clearly showing all the issues and offering clear
> Coming back to the OP, expected is a type to avoid to throw exceptions. It
> would be surprising to me that an exception could be thrown by an implicit
> Are there others that think that implicit conversion to ValueType is a
> good thing to have?
> What makes expected so different from optional to have a different design?
I don't think it should be different from optional.
But expected *is* different than optional - look at the name. You could
argue that "expected" implies that you really did expect the value to be
there, so implicit conversion would not be, well, unexpected. Whereas
optional means the value is optional - being disengaged is just as expected
as being engaged, thus implicit conversion of optional might not be as
But overall, I think the consistency is more important.
You could also argue that optional should have implicit conversion, since
it has already started down the road of "act like T" via things like the
mixed relational operators.
But I worry about implicit conversions (in general) and I'd rather not
bring up any changes to optional that are just design decisions (vs issues
of incompleteness or "unintended consequences").
So overall I _lean_ towards no implicit conversion, but I can see both
sides of it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk