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
>> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk