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