Future of D 2.x as stable/bug fix, and what's next for D 3.x

[bachmeier]

On Thursday, 3 September 2020 at 16:36:46 UTC, Ola Fosheim 
Grøstad wrote:

> E.g. What happens if someone loads the whole file to GC-memory 
> and then retains a pointer to a tiny slice of it. Can the 
> runtime know that only that specific slice is "live"? If it 
> can, then it can release the unused parts surrounding the slice 
> (the big bulk of allocated memory). Can the runtime prove that 
> there is only one reference to the slice? Then it can move it 
> (compaction).

My experience is with mixing R and C. When you write code in C, 
you can tell R to allocate an array (or whatever you want) using 
the GC. It tracks the number of times you do those allocations in 
your C code. You then either release the underlying memory back 
to the GC or you return that memory to R as the return value of 
your function. If you missed something, R throws an error and 
tells you that you didn't release everything.

Naturally, you can still do all kinds of crazy things on the C 
side, including stashing pointers to GC-allocated memory. That's 
how it goes if you want to write C code - it's your 
responsibility to make it work. Everything on the R side is 
guaranteed safe.

I'm not saying this is a strategy D should pursue. Just that it's 
easy to use and it's worked well for decades, allowing you to mix 
your safe GC code with unsafe, GC-free, 
complete-control-of-everything code. There's nothing original in 
anything I've written. All you have to do is track GC allocations 
in the unsafe functions, check your bookkeeping when passing data 
between the two types of code, and enforce the usual @nogc 
restrictions on the relevant code.