On Mon, Mar 31, 2025 at 5:52 PM Jonathan Wakely via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Mon, 31 Mar 2025 at 22:33, Stewart Becker via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On 31/03/2025 09:42, Jonathan Wakely wrote:
>>
>> std::optional<T&> is explicitly not allowing rvalue references, I don't
>> see the committee going the other way for std::expected.
>>
>> Maybe I missed something, but P2988 doesn't seem to mention rvalue
>> references, neither proposing nor actively disallowing them. Has there
>> been any discussion on std::optional<T&&> at all, or it simply not (yet)
>> proposed?
>>
>
> P2988R6 included a partial specialization for optional<T&&>, but P2988R7
> dropped it again. The paper doesn't say why, and the minutes are vague. I
> thought it had been discussed and rejected, but it seems that it was just
> dropped so that the optional<T&> form could make progress without getting
> coupled to a more novel specialization that hasn't been properly designed
> yet.
>

Right, my impression as well (having been in *some* of those meetings but
not nearly all) is that there were serious design decisions to be made
about, for example,
    void f(optional<string&&> o) {
      string s = *o;
    }
Does `optional<string&&>::operator*()` return string&&, because that's the
whole point of having an optional<string&&> instead of just
optional<string&>?
Or does it return string&, because `o` itself is an lvalue you might look
at later? In which case, does it also have an `operator*() &&` so that
`*std::move(o)` will give you the rvalue reference you wanted?
...And so on.
These questions might have relatively easily defensible answers. But those
answers and defenses were not in the paper as presented, and nobody felt
strongly that we needed to ship `optional<T&&>` right now (it's easy to add
later, as far as anyone knows), so let's just wait for a paper to arrive
with the right motivation and answers/defenses. Meanwhile, `optional<T&>`
was well-motivated and well-defended.

I expect that we'll get some of the following in the near future — in
roughly decreasing order of likelihood/motivation —
- `expected<T&, E>`
- `optional<T&&>`, `expected<T&&, E>`
- `variant<T&>` and/or `variant<T&&>`
- `expected<T, E&>` and/or `expected<T, E&&>`

my $.02,
Arthur