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

[Stefanos Baziotis]

On Saturday, 1 June 2019 at 02:40:10 UTC, sarn wrote:
> On Friday, 31 May 2019 at 21:01:01 UTC, Stefanos Baziotis wrote:
>> I'm moving forward with the D implementations of the C parts 
>> that the D Runtime
>> uses.
>
> Hi Stefanos, good project :)
>

Thank you!

> Here's something to consider if you're replacing malloc() et 
> al: it's popular (especially with large server deployments) to 
> tune application memory allocation performance by replacing 
> libc malloc() with alternatives such as tcmalloc and jemalloc.  
> That works because they use the same libc malloc() API but with 
> a different implementation, injected at link or load time 
> (using LD_PRELOAD or something).
>
> It would be great if D code can still take advantage of 
> alternative allocators developed by third-parties who may or 
> may not be writing for D.

As you can see in the "Next Month" above, we're planning to 
replace malloc() et al
but with a different interface. The reason is that we believe that
it is idiomatic D this way (I personally also believe that 
malloc(), free() etc.
have a bad interface for allocation). We even hope that in the 
end (probably
after GSoC) the allocator will be typed.

But the allocators you proposed might be an inspiration for the 
allocator I will build
using the std.experimental.allocator interface.
Moreover, let me stress that malloc(), free().. will be available 
as well.