C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Floating an idea: Dereference operators for std::reference_wrapper

From: Barry Revzin <barry.revzin_at_[hidden]>
Date: Wed, 25 Sep 2024 11:46:18 -0400
On Wed, Sep 25, 2024, 7:30 AM Jonathan Wakely via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Wed, 25 Sept 2024 at 05:53, Jeremy Rifkin via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Hi,
>> It'd be useful for me to have `std::reference_wrapper::operator->` and
>> `std::reference_wrapper::operator*`.
>
>
> Why? You didn't provide any rationale.
>
> Isn't get() already sufficient for everything that operator* could do?
> Do you really need operator->() when refwrap->foo() could be written as
> refwrap.get().foo() instead?
>

For what it's worth, we have a template that inherits from
reference_wrapper<T> specifically for this reason. After a lot of use,
r.get().f() is pretty verbose compared to r->f().

Well that and the name reference_wrapper<T> is also very verbose so ours is
just Ref<T>.



>
>
>
>> As far as I can tell this has not
>> been proposed before. It would follow the precedent of std::optional as
>> well as the forwarding comparison operators added in P2944. Has this
>> been considered before or are there any glaring issues with such a
>> functionality?
>>
>>
> Apart from get() already existing, the main one is that it's a
> **reference** wrapper, and you're proposing pointer-like semantics.
>

I guess you could make the same argument about optional, which is
significantly less pointer-like than reference_wrapper.

Barry

>

Received on 2024-09-25 15:46:32