C++ Logo


Advanced search

Re: [std-proposals] Add more methods to std::initializer_list instead of overloading

From: blacktea hamburger <greenteahamburger_at_[hidden]>
Date: Mon, 12 Sep 2022 20:49:28 +0800
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.

Received on 2022-09-12 12:49:55