C++ Logo

std-proposals

Advanced search

Re: [std-proposals] inplace_vector failable apis

From: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Date: Wed, 22 Nov 2023 10:27:31 -0500
On Wed, Nov 22, 2023 at 10:03 AM Tony V E via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I have implemented it.
>
> It just isn't used that much. So no real implementation experience either
> way. It hasn't been a problem, but neither optional<T&> nor assignment
> come up that much at all, so inconclusive.
>
> If anything, I'd say
>
> Imagine that vector.front() returns an optional<T&>...
>
> As the developer writing vector, I'd like assignment to rebind.
> As the developer using vector.front(), I'd like assignment to not rebind.
>
> auto f = vector.front();
> if (f)
> f = 17; // current optional would not be able to assign from an rvalue
>

That that doesn't compile is actually a pro, not a con. If you want
"assign-through" behavior, you'd write e.g.
    if (f.has_value()) {
        f.value() = 17;
    }
(That is: `f` is an optional that *holds* a reference; 17 isn't a
reference; therefore 17 can't be put into the optional. But f.value() is
the *reference* held by the optional, and you *can* assign 17 into the
variable referred to by that *reference*.)

Initially (before reaching your code snippet), I was going to say "oh yeah,
it *would* be convenient if `vector.front() = 17` would Just Work"; but you
(Tony) aren't even proposing that that *should* work. You're only showing a
more complicated syntax with `if`, where the only difference between the
two snippets is which one better reflects our mental model of `optional`. :)

my $.02,
–Arthur

Received on 2023-11-22 15:27:45