Re: [boost] [optional] Safe optional

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

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

> On Thu, Nov 20, 2014 at 11:00 AM, Andrzej Krzemienski
> <akrzemi1_at_[hidden]> wrote:
> >> > 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
>
> By containers you specifically mean map, right?
> Unordered map for example would not require operator<
>
> Containers (maps) always come up as the primary rationale for operator<
> However, the user could also define his own comparison function for
> this purpose.
>
> Perhaps other use cases of operator< could be presented.
>

I was trying to illustrate how it is useful to think of optional<T> as
extending the domain of T (rather than representing "either T or error").
Not to illustrate the storage in containers.

The user-provided int can be any value of int plus the situation where user
decides not to type any input. the latter is a valid and useful
information. E.g. when an int represents some threshold, having boost::none
means "go with no threshold".  boost::none is just a value. this in turn
implies the implicit conversions:

optional<int>() != 2;

The above is logical and useful, even outside of the containers.

>
> > 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>.
>
> But is it what people have problems with isn't it?
>

Some people are surprised by the implicit conversion, because they expect
it would not be there. the have this expectation because they do not
understand the conceptual model behind optional<T>.

True, they have a problem. I claim, the root of the problem is not
understanding the tool they have.