Boost logo

Boost :

Subject: Re: [boost] [outcome] High level summary of review feedback accepted so far
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-30 20:44:02


2017-05-30 15:51 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:

> On 30/05/2017 13:25, Peter Dimov via Boost wrote:
> > Niall Douglas wrote:
> >
> >> > value() id wide operator*() is narrow.
> >>
> >> Why? Just because optional made that mistake?
> >
> > The motivation here is that in
> >
> > if( o )
> > {
> > o->this_();
> > o->that();
> > o->this_other_thing();
> > o->that_too();
> >
> > o->almost_forgot();
> > }
> >
> > there is needless replication of the check. This, as I already
> > mentioned, stems from a desire to operate on the value inside 'o'
> > directly, which is not my preferred style in result's case, where I'd
> > prefer to extract it instead.
>
> Oh I get that was the motivation, and that's exactly where I find the
> most objection with Optional: it has some pointer semantics, but it is
> not a pointer, and so shouldn't be pretending to be one. It not being a
> pointer should have always been made clear to end users (by forcing them
> type more boilerplate) to extract immediately or else bind a lvalue ref
> to the internally stored value. Don't treat not-a-pointer as a pointer.
>

Maybe, but at least for optional you have one value that you can "refer" to
or not. In case of `expected` it is even harder to defent this, because the
E in a way is also a value.

>
> I also, weirdly enough given the discussion till now, really dislike the
> wide contracts anywhere on Optional. Unlike Expected or Outcome, the
> compiler can instantly tell if you're being stupid when using Optional.
> So I'd have chosen all narrow observers personally, and have the
> compiler error with obvious UB usage and warn if you observe an Optional
> returned by an extern function without checking its state first. But
> that ship has sailed sadly.
>

The primary interface for accessing optional's contained value (operator*
and operator->) have narrow contract.

Regards,
&rzej;


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk