Re: [boost] [optional] Safe optional

Subject: Re: [boost] [optional] Safe optional
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2014-11-18 04:23:51

2014-11-18 8:00 GMT+01:00 Andrey Semashev <andrey.semashev_at_[hidden]>:

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

And to remove operator* and get() and value() and get_pointer() - anything
that could cause UB. And remove implicit conversion from T

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

As explained above: serious backwards incompatibility. Unacceptable by
many, including myself.

>
> >> 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.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>