[GSoC] 'Independency of D from the C Standard Library' progress and update thread

[Sebastiaan Koppe]

On Sunday, 2 June 2019 at 00:10:51 UTC, Mike Franklin wrote:
> The way I envision this playing out is that when 
> std.experimenal.allocator is ported to druntime

You probably don't need or want to port the whole of 
std.experimental.allocator to druntime. I recently looked at the 
GC in druntime and it has it's own pools etc. If it didn't, then 
the mark phase would be a lot harder and slower. (according to my 
understanding...)

Therefor, for normal D programs, the only thing that makes sense 
is to implement the allocator that underlies the GC (an mmap or 
sbrk allocator). And be sure to make it is pluggable.

What I am trying to say is that you can avoid porting the whole 
thing.

> use the `IAllocator` interface.  Therefore, any allocator 
> conforming to that interface could potentially serve as 
> druntime's allocator.

I am not a big fan of the IAllocator interface since it 
introduces a layer of indirection. There is no simple solution to 
avoid the indirection and get a pluggable allocator. Well, maybe 
a combination of ldc's @weak and LTO. Dunno...

https://wiki.dlang.org/LDC-specific_language_changes#.40.28ldc.attributes.weak.29
http://johanengelen.github.io/ldc/2016/11/10/Link-Time-Optimization-LDC.html