On Fri, Feb 20, 2026 at 5:32 PM Marcin Jaczewski <
marcinjaczewski86_at_[hidden]> wrote:

> pt., 20 lut 2026 o 20:46 Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> napisał(a):
> > On Fri, Feb 20, 2026 at 1:39 PM Marcin Jaczewski via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >>
> >> Paper suggests rewriting `ptr->meber` by `(*ptr).member`.
> >>
> >> But this creates an interesting case, new `->` created this way will
> >> have capabilities impossible compared to manually written `->`.
> >
> > Yes, and P3039R1 mentions that it does, in §6:
> >> Simply removing the operator-> definition from classes could possibly
> cause a different member function to be invoked. Specifically if the
> operator* that is chosen returns an rvalue reference and we are invoking a
> member function that has been both lvalue and rvalue reference qualified:
> using operator-> would cause the lvalue qualified form to be invoked but
> using operator* would cause the rvalue qualified form to be invoked. This
> may cause subtle behaviour changes.
> >
> > However, I do see that §6.4 erroneously lists `optional` as one of the
> types that "have an operator-> that is identical to what the rewrite would
> accomplish." In fact, `optional` is one of the poster-child types that are
> intended to become more powerful with the rewrite.
> >
> > // https://godbolt.org/z/ah5jEjsvP
> > [...]
> > Actually, the reference implementation on Godbolt gets this example
> wrong, so maybe this effect was unintended too (although I'm not sure how
> to square that with the quotation from §6, which seems to indicate that the
> authors were very much aware of this effect).
>
> As far as I know it works fine, the only problem is that you have
> defined `operator->` that blocks this overwrite


Ah, right, OK. That works fine then!
So thankfully that "wrongness" was just a red herring, and we can safely
use `optional` as another example where P3039 intentionally makes rewritten
-> more powerful than an existing operator->.

Cheers,
Arthur