Re: [boost] [optional] Safe optional

Subject: Re: [boost] [optional] Safe optional
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-11-18 02:00:12

On Mon, Nov 17, 2014 at 12:24 PM, Andrzej Krzemienski
<akrzemi1_at_[hidden]> wrote:
>
> The solution is based on the observation that there is a limited number of
> things you can do with optional<T>
>
> optional<int> oi = ...;
>
> 1:
> if (oi) doSomething(*oi);
> else doSomethingElse(); // or nothing
>
> 2:
> if (oi) doSomething(*oi);
> else doSomething(-1); // use default value
>
> 3:
> if (!oi) oi = (int)getIntByOtherMeans();
> doSomething(*oi); // now it is safe
>
> Now we simply provide a dedicated interface for each of these three usages:
>
> 1:
> oi.use(&doSomething, &doSomethingElse); // or use lambdas

I'd call it visit(). Also, a one argument visit() could be useful (the
visitor would be passed boost::none if the value is absent).

> 2:
> doSomething(oi.value_or(-1));

We already have that.

> 3:
> doSomething(oi.value_or_eval(getIntByOtherMeans));

So, basically, the proposal is to add visitation API, am I correct? In
that case why not add it to the regular optional?

IMHO, in order to introduce an alternative component, there should be
significant and incompatible design and interface differences between
the two. So far I don't see the need for such differences.

>> Regardless, if people come to an agreement on changes, I'm much more in
>> favor of simply making breaking changes to the current optional rather than
>> introducing another one. It's unfortunate for a type as fundamental and
>> widely used as optional, but people will get over it, especially if it
>> makes it closer to the standard proposal.
>
> I would rather not go that way. boost::optional is not unsafe. It is simply
> something else than what some people think. Its conceptual model is more
> like any value of T, plus one additional value. In this model implicit
> conversions make perfect sense and are n fact desirable.

Exactly. Vladimir's example is an illustration of this.