new should lower to a template function call

[Andrei Alexandrescu]

On 7/23/20 2:51 PM, Stefan Koch wrote:
> On Thursday, 23 July 2020 at 00:47:21 UTC, Andrei Alexandrescu wrote:
>> Was thinking about this, see 
>> https://issues.dlang.org/show_bug.cgi?id=21065.
>>
>> One problem I noticed with the current instrumentation of allocations 
>> is that it is extremely slow. https://github.com/dlang/dmd/pull/11381 
>> takes care of that trivially and quickly because it takes advantage of 
>> defining one static variable per instantiation.
> 
> As Mathias has already point out in your issue.
> You are instantiating more templates.
> 
> In the _worst_ case this can almost double the number of template 
> instances.
> I.E. when the new is inside a template itself.

Not a problem. We must go with templates all the way, it's been that way 
since the STL was created and there's no going back. All transformations 
of nonsense C-style crap into templates in object.d have been as many 
success stories. If anything there's too few templates in there.

When "new C" is issued everything is right there for the grabs - 
everything! The instance size, the alignment, the constructor to call. 
Yet what do we do? We gladly throw all that on the floor to call a 
crummy C function that uses indirect access to get access to those. No 
wonder -trace=gc is so slow. This entire inefficient pomp and 
circumstance around creating an object is an embarrassment.

To say nothing about built-in hash tables. It's 2020 and we still use an 
indirect call for each comparison, right? We should make a vow to fix 
that until the next Pandemic.

> What do you envision the prototype to be like, and why couldn't that be 
> just a function call to the runtime if a hook exists?

In the simplest form:

template __new_instance(C)
if (is(C == class))
{
     static foreach (all overloads of __ctor in C)
     {
         C __new_instance(__appropriate__parameter__set)
         {
             ...
         }
     }
}

This would be a terrific opportunity to fix the perfect forwarding problem.

Further improvements: use introspection to detect if the class defines 
its own __new_instance, and if it does, defer to it. That way the 
deprecated feature per-class new makes a comeback the right way.