d future or plans for d3

[Vladimir Panteleev]

On Sunday, 18 December 2011 at 23:19:08 UTC, Adam Wilson wrote:
> It seems to that we are really dancing around the potential 
> solution. A pluggable GC interface that allowed the developer 
> to choose the right GC for the task, or no GC at all. Imagine 
> if all the developer had to do is set a compiler switch and the 
> compiler automatically linked in the correct GC for the job. D 
> could ship with a default GC then others could write different 
> GC's based on different paradigms or their own needs. It would 
> be a piece of work to get the interfaces right, but definitely 
> worth it in the long run.

This pretty much already describes the current situation.

This is the interface: 
https://github.com/D-Programming-Language/druntime/blob/master/src/core/memory.d#L19

You can install your own GC as a "proxy" (this is used for 
sharing the heap with shared objects):

https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L33

> Theoretically this would also give the developer the ability to 
> link in multiple collectors and switch between them during 
> program execution, provided the working set data was stored in 
> a common format; although I have never heard of a use case for 
> such a capability.

It would probably be more practical to allow one GC to be 
configurable at runtime.

> I think supporting a NoGC environment is a good idea in the 
> long run as their are cases to be made for manual memory 
> management, but it also shouldn't be our first goal. GC's are 
> were the value is.

I believe there have been several attempts to start a no-GC 
runtime+stdlib (including one of mine), but they never got off 
the ground.