D Language 2.0

[BCS]

Hello bearophile,

> 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.
> 

I think the approach would be to take whatever parts of phobos you can make 
work without the GC and *without making them suck* and do so.

Also, given that -nogc could be done just as a static check without any effect 
on the emitted code, any code that is valid without a GC is valid with it 
(aside from issue of the GC not being able to find pointers but I don't think 
that apply here).

> A better strategy is first of all to improve a lot the D GC, if

That's true regardless :)

> 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.

being ABLE to avoid it is always a plus. One use I see is perf critical code 
kernels being compile with -nogc and linked to from non critical code compiler 
without -nogc

> 
> Bye,
> bearophile