On 30/04/2022 12.04, Frederick Virchanza Gotham via Std-Proposals wrote:
>
>
> On Saturday, April 30, 2022, Jens Maurer <Jens.Maurer_at_[hidden] <mailto:Jens.Maurer_at_[hidden]>> wrote:
>
>
> If you want to disable template argument deduction for a function parameter,
> just do it (see [meta.trans.other]):
>
> template<class T>
> /* whatever */ Add_Or_Max(std::type_identity_t<T> const a, std::type_identity_t<T> const b);
>
> Since T only appears in non-deduced contexts, a user needs to specify
> it explicitly in the template-argument-list of the function call.
>
>
>
> Nobody wants to open up a colleague's SVN commit and scroll down through code that looks like that. It isn't streamlined to read, especially when you're thinking about 2 or 3 things at once, and then you have to think "oh I know that trick there with type_identity_t". The following is much more minimalist and easy to understand at a glance:
>
> template<explicit class T>
> T Add_Or_Max(T a, T b);
>
> We designers of computer programming languages (or we hobbyists with an interest in designing computer programming languages), must empower the programmer to write minimal clean code to get the job done well -- such as when 'virtual' methods were invented so that we could have abstract base classes.
>
> I know that we can use 'type_identity_t' here but it's clunky syntax which interrupts the reader's train of thought. Also it involves including a standard header file <type_traits> simply just to declare a function.

Please make sure any eventual paper emanating from the present
discussion clearly shows that workaround and the rationale why
you believe it isn't good enough.

Eventually, EWG will need to make a judgment call whether your
assertions of "clunky syntax" and "Nobody wants to [...] scroll
down through code that looks like that" bears the weight of a
core language extension that strives to replace a functionally
equivalent library-only solution.

Showing plenty of use-cases in the wild, beyond your job at work,
would also help to bear that weight.

Note that the comparison with virtual member functions is orders
of magnitudes different here. (What would a library-only solution
for those look like, including supporting virtual inheritance?)

Jens