new should lower to a template function call

[Andrei Alexandrescu]

On 7/24/20 1:14 PM, Johan 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.
> 
> Reliance on runtime type information for object creation is not good, I 
> agree. But that is easily solved by having the compiler make a call to 
> the ctor (instead of implementing that call in druntime). Another option 
> is to templatize, as you wrote.

Thanks for answering! I was deliberately exaggerating for dramatic 
purposes, so it's great to see such an even-keeled analytical response.

> 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.
> 
> Templatizing will make certain types of functionality _harder_. If a 
> library/program wants to break, or hook into, object creation inside 
> user code, it will be impossible with templatized functions (you cannot 
> predict the templated function names of code that has not yet been 
> written). For example, AddressSanitizer can only work with 
> non-templatized allocation functions. If malloc was a template, it would 
> be _much_ harder to implement AddressSanitizer support (and currently 
> not possible while keeping source location in error messages).

I think there's a simple pro-template argument that I've run into often 
in my C++ projects: template to non-template is a one-way street because 
from static type information to non-static type information is a one-way 
street. You can go from a templated approach to a non-templated approach 
as easy as a one-liner. You can go from static composition to dynamic. 
You can do type erasure but not type "reconstruction". Going the other 
way is much more difficult for obvious reasons.

That's why deferring the decision to lose type information is often a 
good stance for a designer; it offers maximum flexibility because you 
can easily revisit and override it.

(This argument pattern goes for other things, too: making a fast 
subsystem safe vs. the converse comes to mind.)

Applied to druntime, if using runtime functions is desirable, the 
templates can just forward to them. So once we decide to use templates 
for fundamental runtime support, changing our mind selectively is 
trivial. Going the opposite way (which is what we're doing now) is a 
difficult path with compiler changes and all.

> In favor of compiler-implemented code (instead of druntime) is that the 
> compiler is able to add debug information to generated code, linking the 
> instructions to source location in user code. I think this will only be 
> possible for druntime-implemented when: a) the code is force-inlined and 
> b) there is a way to disable debug information tagging of the 
> instructions inside the druntime-implemented function (such that the 
> source-location stays the same as the user's code). (a) is already 
> available in our compilers, (b) is not yet.
> 
> Template bloat is a standard concern, because we do not have any defense 
> against it. Did anyone ever look into the array comparison case with 
> template bloat? Force-inlining _and_ not emitting into binary (currently 
> not available to user/druntime code) would fix that, although then maybe 
> someone else starts to argue about instruction count increase...

I'm tuned to some of the C++ standardization mailing lists. Template 
bloat has come into discussion about every template-related feature 
addition since 1990. Occasionally with numbers. Over time these 
arguments died out: the ease of opting out of templates where 
appropriate and the many tactical improvements made by compiler writers 
have simply sent that argument to the dustbin of history. All C++ 
features of any consequence since decades are imbued with genericity.

It has been undeniable that going templated all the way has worked 
wonders for C++. We'd do good to learn from that.