Date: Thu, 25 Sep 2025 05:55:15 -0700
I'd had a different thought overnight. What about allowing one to
add `auto operator->() = default;`. If this is selected by overload
resolution, then behave as in paragraph 2 of [expr.ref] (rewrite the
code as `(*(E1)).E2`) instead of the behaviour in [over.ref] (the
current "keep calling operator-> until you get a raw pointer, then
rewrite to (*(E1)).E2") . The practical result is that instead of
using the overloaded operator->() and calling operator-> on the result
of that, use the overloaded operator*() and apply the dot operator on
the result of that. This moves the type decisions over to operator*
where the reference-qualifications are preserved.
On Thu, Sep 25, 2025 at 1:01 AM Marcin Jaczewski via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> czw., 25 wrz 2025 o 08:55 Jan Schultke via Std-Proposals
> <std-proposals_at_[hidden]> napisaĆ(a):
> >
> > > Is this not easily fixable by converting the:
> > >
> > > constexpr T* operator->() {...}
> > > constexpr T const* operator->() const {...}
> > >
> > > with just:
> > >
> > > constexpr T* operator->() & {...}
> > > constexpr T const* operator->() const& {...}
> >
> > Making operator-> reference-qualified in general is a bad idea. It
> > prevents valid use cases like:
> >
> > getAddress()->modify()
> >
> > or
> >
> > getOptionalBuilder()->set(1).build()
> >
> > Also I'm pretty sure that the const& overload works with rvalues.
>
> Overall I think `->` is somewhat broken as it makes it hard to use
> some proxy objects too.
> One solution I had it create "final" operator `->` that return
> refs/values instead of pointer, like:
>
> ```
> T& operator->(int) { ... } //int is to inform compiler that is not
> normal operator `->`
> ```
>
> Compiler will stop chaining `->` on this overload (instead of stopping
> on buildin `->`).
>
>
>
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
add `auto operator->() = default;`. If this is selected by overload
resolution, then behave as in paragraph 2 of [expr.ref] (rewrite the
code as `(*(E1)).E2`) instead of the behaviour in [over.ref] (the
current "keep calling operator-> until you get a raw pointer, then
rewrite to (*(E1)).E2") . The practical result is that instead of
using the overloaded operator->() and calling operator-> on the result
of that, use the overloaded operator*() and apply the dot operator on
the result of that. This moves the type decisions over to operator*
where the reference-qualifications are preserved.
On Thu, Sep 25, 2025 at 1:01 AM Marcin Jaczewski via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> czw., 25 wrz 2025 o 08:55 Jan Schultke via Std-Proposals
> <std-proposals_at_[hidden]> napisaĆ(a):
> >
> > > Is this not easily fixable by converting the:
> > >
> > > constexpr T* operator->() {...}
> > > constexpr T const* operator->() const {...}
> > >
> > > with just:
> > >
> > > constexpr T* operator->() & {...}
> > > constexpr T const* operator->() const& {...}
> >
> > Making operator-> reference-qualified in general is a bad idea. It
> > prevents valid use cases like:
> >
> > getAddress()->modify()
> >
> > or
> >
> > getOptionalBuilder()->set(1).build()
> >
> > Also I'm pretty sure that the const& overload works with rvalues.
>
> Overall I think `->` is somewhat broken as it makes it hard to use
> some proxy objects too.
> One solution I had it create "final" operator `->` that return
> refs/values instead of pointer, like:
>
> ```
> T& operator->(int) { ... } //int is to inform compiler that is not
> normal operator `->`
> ```
>
> Compiler will stop chaining `->` on this overload (instead of stopping
> on buildin `->`).
>
>
>
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-09-25 12:55:29