new should lower to a template function call

[Atila Neves]

On Friday, 24 July 2020 at 03:29:14 UTC, Andrei Alexandrescu 
wrote:
> On 7/23/20 9:34 AM, jmh530 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.
>> 
>> How does this fit in with plans for 
>> std.experimental.allocator? What are the current plans for 
>> std.experimental.allocator?
>
> Allocators need a champion. Ideally a good integration with the 
> GC would be achieved but I'm not a GC expert and don't have the 
> time to dedicate to it.
>
> As far as I know there's little use of allocators, which is 
> unlike C++ where there's a lot of excitement around them in 
> spite of a much scarcer API. I recall there's a little use of 
> allocators (copied to code.dlang.org and improved) in Mir. Not 
> much else I've heard of.
>
> I was hoping there'd be a lot of experimentation accumulating 
> with new allocators by now, for example to this day I have no 
> idea whether FreeTree is any good. (It never rebalances, but I 
> thought I'd wait until someone says the trees get lopsided... 
> still waiting).

The main issue right now with allocators IMHO are language 
changes that would allow for the writing of @safe smart pointers 
and the like.

Currently, opting out of the GC means putting up with C++-style 
memory safety bugs. Thankfully ldc gives us asan, but while that 
helps it's definitely not a silver bullet.

I want to come up with a DIP but have been busy trying to fix 
template code emission issues , which also tie into build times.