Re: [boost] [optional] Safe optional

Subject: Re: [boost] [optional] Safe optional
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2014-11-20 05:00:34

2014-11-20 10:49 GMT+01:00 Olaf van der Spek <ml_at_[hidden]>:

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

I disagree with this statement. In case of optional<T> having no value of T
is deliberately treated as a yet another value. This has a well defined
purpose. It is covered in the documentation here:
http://www.boost.org/doc/libs/1_57_0/libs/optional/doc/html/boost_optional/quick_start/storage_in_containers.html

the docs also recommends NOT to use optional<T> to signal a potential
error/difficulty in computing T:
http://www.boost.org/doc/libs/1_57_0/libs/optional/doc/html/boost_optional/tutorial/when_to_use_optional.html
.

This is the choice made for optional<T>. The authors of expected<T, E> may
want to choose a different model.

> What's wrong with being explicit with what you want, especially in
> ambiguous situations like those mixed comparisons?
>

Nothing wrong with that. It is just not the job for optional. Perhaps a job
for expected<T, E>.