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.