D Language 2.0

[Andrei Alexandrescu]

bearophile wrote:
> Andrei Alexandrescu:
>> I'd love -nogc. Then we can think of designing parts of Phobos to work 
>> under that regime.
> 
> But you must do this with lot of care: programmers coming from C++ will be tempted to write code that uses those GC-free parts of Phobos a lot, the end result will be a lot of D code in the wild that's like C++ or worse. So when you want to use one of those modules or libraries, you may need to dance their no-GC dance. This can invalidate the good idea of designing a GC-based language.
> 
> A better strategy is first of all to improve a lot the D GC, if necessary to introduce in the language other details to help the design of a more efficient GC (like giving ways to tell apart pinned objects from normal ones, make the unpinned ones the default ones, and modify the type system so mixing pinned-memory and unpinned-memory pointers is generally safe, etc). Only when further improvements to the GC become too much hard, you can start to write no-GC parts of Phobos, few years from now.
> 
> I have seen many cases where Java code run with HotSpot is faster than very similar D1 code compiled with LDC. Avoiding the GC is a easy shortcut, but I think it's not a good long-term strategy for D.
> 
> Bye,
> bearophile

Walter and I talked for hours about a no-gc model for D, and the 
conclusion was that with only a little compiler support, things can be 
arranged such that swapping different object.d implementations, the 
entire D allocation model can be swapped between traditional GC and 
reference counting.

But there's a long way from here to there. One essential thing to be 
done is transform built-in arrays into normal types defined in object.d. 
(Walter just did this for associative arrays.) Then some special steps 
must be taken about Object and the semantics of new. Essentially all 
allocation primitives must forward to functions or template functions 
defined in object.d. With such a system in place, object.d can 
essentially gain entire control about an entire program's memory 
management policy.

I don't have the time to pursue this at the moment, but I'm sure I will.

Walter and I are very convinced that the approach based on 
rewriting/lowering is very promising.


Andrei