Re: [boost] [optional] Safe optional

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

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

> On Tue, Nov 18, 2014 at 12:23 PM, Andrzej Krzemienski
> <akrzemi1_at_[hidden]> wrote:
> > 2014-11-18 8:00 GMT+01:00 Andrey Semashev <andrey.semashev_at_[hidden]>:
> >>
> >> 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.
>
> I see. In this case I agree in that the original optional should
> remain the same. However, I don't see much point in such a restricted
> subset of the current optional. Just imagining myself using
> functions/lambdas instead of get() and similar code makes me dizzy.
>

I sympathize with your opinion. Personally, I also prefer the current way
of accessing the value. Yet, I see people complain that it is unsafe. It is
my hypothesis that there exist a portion of users that just like the
monadic interfaces along with the inconvenience that comes with it. This
post is to confirm my hypothesis, and if it is the case, to satisfy the
demand.

> IMO, visitation API could be useful for generic code (i.e. which
> already uses boost::visit or similar facility and is as such
> compatible with boost::variant). It's not a direct replacement for
> extraction API (i.e. getters), it's just too cumbersome. I had
> realized this when I was working on Boost.Log and ended up with both
> interfaces to attribute values - each has its strong and weak sides
> and is more useful than the other in some cases.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>