new should lower to a template function call

[Andrei Alexandrescu]

On 7/24/20 2:07 PM, H. S. Teoh wrote:
> Template bloat is also a cause of concern: if your program had arrays of
> 100 distinct types, but they are all PODs and therefore comparison could
> be done with memcmp()'s, then it makes little sense for the compiler to
> instantiate the array comparison template 100 times and emit 100 copies
> of code that ultimately is semantically identical to memcmp.

We do exactly what you describe would be desirable. All comparisons of 
arrays of scalars boil down to a small code:

https://github.com/dlang/druntime/blob/master/src/core/internal/array/comparison.d#L50

See generated code:

https://godbolt.org/z/4hjWxq

(dmd does not inline that, hopefully it will in the next release. Does 
not dilute my argument.)

> Ditto for
> any other array operation that you have have.  Force-inlining only helps
> to a certain extent -- as Johan said, you merely end up with instruction
> count bloat in lieu of template function bloat. At some point, the cost
> of having an overly-large executable will start to outweigh the (small!)
> performance hit of replacing instruction count bloat with a function
> call to memcmp, for example.

As I said, with templates you have precise control over merging 
implementations, inlining vs. not, certain optimizations etc. Without 
templates - you don't. It's as simple as that. To paraphrase Steven 
Wright, going non-templates is a one-way dead-end street.

> Another problem is error messages, as someone else has already pointed
> out.  Although we have seen improvements in template-related error
> messages, they are still very user-unfriendly, often coming in the form
> of indirect messages like "this call does not match any of the following
> 25 overloads", and the user has to sift through pages upon pages of
> indecipherably-long template symbols and somehow deduce that what the
> compiler *really* want to say was "you have a typo on line 123".

There is great opportunity to improve compilers, some of which has been 
reaped, and much of which is still waiting.

> I think part of the solution is to adopt Stefan's proposed type
> functions instead of shoe-horning everything into templates. Just
> because templates are Turing-complete does not necessarily mean they are
> practical for implementing every computation. A lot of the druntime
> templates / prospective druntime templates could possibly be implemented
> as type functions rather than template functions.

That'd be interesting. In the meantime, there's so much to do with the 
current template offering it hurts.