sob., 30 kwi 2022 o 13:16 Jens Maurer via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> 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?)
>

Interestling, virtual member functions get library-only replacement in:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p0957r7.pdf
Not exacly same functionality but in many cases easier to use with
unrealted types.

> Jens
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals