On Wed, 25 Sept 2024, 16:48 Barry Revzin, <barry.revzin@gmail.com> wrote:


On Wed, Sep 25, 2024, 7:30 AM Jonathan Wakely via Std-Proposals <std-proposals@lists.isocpp.org> wrote:


On Wed, 25 Sept 2024 at 05:53, Jeremy Rifkin via Std-Proposals <std-proposals@lists.isocpp.org> 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.