I think adding new features requires trade-offs. Users need to become more
careful, but that's not too hard. More importantly, it brings many benefits.

On Mon, Sep 12, 2022 at 8:36 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:

> On Mon, 12 Sept 2022 at 15:30, blacktea hamburger via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> > The only thing they (free functions in some hidden corner) can do is
> make otherwise wrong code compile.
>
> They can also make correct code compile with unintended consequences.
> When you have UFCS, you can
> write code using x.f() so that it calls a f(x), and now you have a
> dependency on that remaining valid. If that
> dependency never forms, you don't have to rely on long-distance code
> staying like you expect it to.
>
> >If you provide a member function (as long as it makes the call legal)
> then the free functions will never be selected.
>
> Right, and if you don't, the free functions will be selected, which
> becomes a problem.
>
> > Private members not participating in the user's overload resolution will
> also only make wrong code compile, because now an error will be generated
> if the overload resolution selects a private member function.
>
> ..and attempt to make calls ill-formed will now behave differently
> because overload resolution looks at something else
> than previously expected. There have traditionally been rather
> convincing arguments against skipping privates
> in overload resolution, but I'm not entirely sure I can
> present/describe them accurately - that doesn't mean they don't exist,
> though.
>