Re: [boost] [optional] Safe optional

Subject: Re: [boost] [optional] Safe optional
From: Olaf van der Spek (ml_at_[hidden])
Date: 2014-11-20 04:49:06

On Thu, Nov 20, 2014 at 10:29 AM, Andrzej Krzemienski
<akrzemi1_at_[hidden]> wrote:
>> On the second thought I might probably agree that op<() might be
>> questionable... Can we address that differently then?
>>
>
> No. Allowing this comparison to work is the right thing to do. It is a
> natural consequence of Optional's conceptual model. You should look at
> optional<T> as a T plus one additional value, less than any other value.
> No-one stops you from adopting any other model (like container of size
> 0-or-1), but then you are risking that you will be surprised by the result.
>
> Optional is not a container of size 0-or-1. You do not expect an element to
> be implicitly converted to its container type.
>
> The source of the confusion in this example above is the wrong expectation
> that the compiler will warn you about any place where optional<T> is
> confused with T. They are supposed and expected to be confused and mixed.
> That's the idea behind implicit conversions.
>
> Yet, many people make this invalid expectation, because what they are
> really looking for is something different: something that will detect as
> many potential programmer errors as possible (including false positives).
>
> Note that the proposed expected<T, E> has the same "identity crisis":

It'll probably face the same resistance.
Comparing no value and a value simply doesn't make sense and code like
shown is a real bug.
What's wrong with being explicit with what you want, especially in
ambiguous situations like those mixed comparisons?

-- 
Olaf