Hi,
Thanks for the reply.

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

To elaborate on rationale: Ergonomics and consistency.

I'd find operator-> useful for the same reason std::optional::operator->
is useful: Even though we could write optional.value().foo(), it
provides nice ergonomics.

> Apart from get() already existing, the main one is that it's a
> **reference** wrapper, and you're proposing pointer-like semantics.

From my perspective, and others may disagree, the precedent set by types
like optional expands the semantic meaning of -> and *.

I'm mainly interested in ->, * is just for symmetry and consistency with
the std::optional precedent.

I find it inconsistent that some wrapper types like optional (I think
this is an uncontroversial characterization) have -> while something
like reference wrapper doesn't. It'd be nice, imo, to be able to always
use the -> shorthand for accessing members on wrapped values.


Cheers,
Jeremy



On Sep 25 2024, at 6:29 am, Jonathan Wakely <cxx_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?
>>
>>
>>
>>
>>> 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.