On 2022-05-03 at 08:51, Abdullah Qasim via Std-Proposals wrote:
> But here is the thing:
>
> Why not make code simpler??
>
> Why write multiple “= delete” functions, conscientiously tracking all
> conversions, when explicit inside functions is much simpler??

The argument against some new features is that the thing you want to do
is already possible in the existing language.

So why do we want yet another way of doing something? Something that in
practice is done very seldom.

There is a cost for the compiler writers in implementing the feature,
and for everyone else in learning what this new syntax means.

Does this "much simpler" way earn back those costs? As the proposer, you
ought to show that it obviously does.

>
> Also, someone suggested explicit template parameters, like this:
>
> *template <explicit typename T>*
>
> Why not have consistence, & allow:
>
> *int func (explicit int x, int y)*
>
> as well?
>
> *From: *Jason McKesson via Std-Proposals
> <mailto:std-proposals_at_[hidden]>
> *Sent: *01 May 2022 22:07
> *To: *std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>
> *Cc: *Jason McKesson <mailto:jmckesson_at_[hidden]>
> *Subject: *Re: [std-proposals] explicit keyword (new use)
>
> We have `= delete` for removing unwanted conversions. Indeed, you can
> basically force the use of `int` with:
>
> template<typename T>
> int func (int, T) = delete;
>
> Any call to `func` that doesn't pass an `int` as the second parameter
> will fail to compile. Even things convertible to `int` will not be
> used.
>
> If you want to allow more things to call it, you can only cull out
> floating-point types with this overload:
>
> int func(int, double) = delete;
>
> Calling func(5, 1) will work, but func(5, 3.4) or even func(5, 2.3f)
> will fail. This preserves the ability to call it with types
> convertible to `int` (but those which are convertible to `int` *and*
> floats will fail due to ambiguity).
>