Boost logo

Boost :

Subject: Re: [boost] [outcome] Second high level summary of review feedback accepted so far
From: Peter Dimov (lists_at_[hidden])
Date: 2017-05-30 21:49:16

Vicente J. Botet Escriba wrote:

> Do you want that boost.shared_ptr checks if not null before access on
> operator->?

Checking in shared_ptr::op-> is narrow, by the way, and I regret putting
that in. Should have been wide. Now we have endless debates whether to drop
the noexcept because LWG guideline. (A daft guideline if you ask me, but
that's what happens when people don't understand what the words "undefined
behavior" mean.)

To expand on that a bit:

    T* operator->() const noexcept;
    Requires: get() != nullptr.
    Returns: get().

Narrow, a mistake.

    T* operator->() const noexcept;
    Returns: get().

Wide, as it should have been.

Now of course I wouldn't widen it like

    T* operator->() const;
    Returns: get().
    Remarks: If get() == nullptr, throws bad_pointer_access().

because obviously I don't want shared_ptr to introduce overhead here over a
raw pointer.

But outcome<T> is not a pointer and is not used as such. Throwing on value
access when there's no value is actually an intended use, not something that
signals a logic error. It doesn't throw logic_error, it throws the actual
exception stored in the outcome by the producer.

All that said, I'm actually not opposed to outcome<T>::op-> being the second
above (the equivalent of value_if) and op* being effectively *operator->().
I was opposed to their existence, but if they are the price we need to pay
to placate the concerns of the group wanting a narrow interface, so be it.

Boost list run by bdawes at, gregod at, cpdaniel at, john at