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
