new should lower to a template function call

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Jul 24 18:07:21 UTC 2020


On Fri, Jul 24, 2020 at 05:14:47PM +0000, Johan via Digitalmars-d wrote:
> On Friday, 24 July 2020 at 14:06:28 UTC, Andrei Alexandrescu wrote:
> > We need to template all we can of druntime. All those silly C-style
> > functions decaying to void* and dependencies and runtime type
> > information must go.
[...]
> I don't agree that everything should be moved to templates in
> druntime, but I cannot formulate a strong argument against it (I also
> have not seen strong arguments in favor of it though). Because
> "careful consideration" is not a strong point of D development, I am
> wary.

I think, as with all things in language development, there's a
trade-off. Templates are not a silver bullet. For example, the
string-switch fiasco that somebody referred to. Ultimately, IIRC, that
was worked around by rewriting std.datetime to refactor away that giant
1000+ (or was it 5000+) case switch statement -- but that did not fix
the real problem, which is that when you have a very large number of
template arguments, it just introduces a lot of problems, both in the
compiler (performance, size of generated symbols, etc) and in the binary
(ridiculous size of symbols, template bloat).

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. 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.

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".

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.


T

-- 
Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG


More information about the Digitalmars-d mailing list