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:
> 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:
> > .
> > This is the choice made for optional<T>. The authors of expected<T, E>
> > 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
> > 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.