I was aware of this effect as it was the motivation for me to adopt the
paper. In my case I’d put an object with a deleted rvalue-qualified
function into the optional, used operator-> to invoke it (not entirely
intentionally), and was then surprised that the compiler accepted the
code. I was expecting it to fail.

On Fri, Feb 20, 2026 at 2:54 PM Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
wrote:

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