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

[sarn]

On Saturday, 1 June 2019 at 14:18:25 UTC, Stefanos Baziotis wrote:
> Moreover, let me stress that malloc(), free().. will be 
> available as well.

Do you mean you're planning to allow the stdlib's allocation 
backend to be switched completely to libc-style malloc() and 
free(), or just that developers can always import 
core.stdc.stdlib and call malloc() if they like?  (The second 
option won't be enough.)

One option is to design D's allocation so that users can link 
with wrapped versions of tcmalloc, etc.  However, it's important 
that this be designed properly so that it doesn't require a 
custom compiler toolchain, otherwise it'll just be a theoretical 
thing that no one actually does.  Preferably it would work with 
LD_PRELOAD.

I like the idea of moving beyond libc's API, but please consider 
and test this use case.  A lot of smart people outside D are 
working on allocators, and it would be a major disadvantage if D 
can't use them.