Re: [boost] [gsoc-2013] Boost.Expected

Subject: Re: [boost] [gsoc-2013] Boost.Expected
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-05-02 12:39:07

On May 2, 2013, at 10:17 AM, Gottlob Frege <gottlobfrege_at_[hidden]> wrote:

> On Wed, May 1, 2013 at 8:23 PM, Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]> wrote:
> 
>> 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.

+1

>> 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 conversion.
>> 
>> Are there others that think that implicit conversion to ValueType is a
>> good thing to have?

I think it could prove handy, but may cause unintended consequences.

>> What makes expected so different from optional to have a different design?
> I don't think it should be different from optional.

They should be similar so long as the similarity isn't forced.

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

That is reasonable.

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

Agreed.

> But overall, I think the consistency is more important.

"A foolish consistency is the hobgoblin of little minds."

I'm not suggesting you're being foolish or that you have a little mind. I mean only to caution against making consistency, among unrelated types, too 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.

I'd argue against it.

> But I worry about implicit conversions (in general)

+1

> and I'd rather not bring up any changes to optional that are just design decisions (vs issues of incompleteness or "unintended consequences").

I agree with that sentiment, but I also don't want the wrong thing enshrined in the standard.

> So overall I _lean_ towards no implicit conversion, but I can see both sides of it.

I think there's a good case for no implicit conversion for optional and having it for expected. However, omitting it for both is safer and satisfies the consistency wish.

___
Rob

(Sent from my portable computation engine)