On Wed, 25 Sept 2024, 16:48 Barry Revzin, <barry.revzin_at_[hidden]> wrote:

>
>
> 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.
>


It's nullable, which might have been the original motivation for treating
it like a pointer. There's also a valid reason to have a checked accessor
that throws, value(), and an unchecked one, with some alternative syntax.
For reference wrapper it's not nullable and doesn't need to be checked, so
only needs one accessor.