D without a GC (Was: Advocacy (Was: Who here actually uses D?))

[Vladimir Panteleev]

On Sun, 02 Jan 2011 21:57:50 +0200, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> Sure, but D has *optional* gc. If you want to, you can use D as simply a  
> "better C" and it will compile to the same code as C does.

The usual comeback to that is that Phobos depends on the GC, so a great  
part of the standard library was unusable without memory leaks. I think  
this is an interesting problem, and solving it could both prove that D  
*is* practically usable for nontrivial tasks without a GC, and provide a  
solution for those who can't or don't want to use a GC (you may have  
noticed how many upvotes the stackoverflow comment about people just not  
wanting to use a GC got).

How much of D can you really use without Phobos? I imagine there'd be no  
problem in using it as a better C, but there isn't much appeal to that,  
compared to C++/STL/Boost. A practical No-GC D solution would probably  
have to include a standard library that works without a GC.

Some ideas:
* A while ago, it was suggested that there be a version(NO_GC) or  
something like that, and the standard library could be modified to work  
differently depending on that version flag. It's probably not practically  
possible, though, because some functions would not make sense in a GC-less  
context (lack of GC would require changing their signature/documentation),  
and the code would quickly become a jungle.
* Forking Phobos into a new standard library based on STL-like  
RAII/refcount constructs (std::string, std::vector) instead of built-in  
arrays, etc.
** The biggest problem with the above idea is that we're back to typing  
long type names instead of having the luxury of built-in dynamic  
arrays/AAs. There could be a language mode (controlled by a compiler  
switch) which maps the syntax for built-in arrays/AAs to RAII/refcounting  
library types.

-- 
Best regards,
  Vladimir                            mailto:vladimir at thecybershadow.net