D Language 2.0

[asd]

Andrei Alexandrescu Wrote:

> > Why would having one chunk of code get checked for calls to the GC and 
> > another not be any more complicated than mixing 
> > malloc/free+add/removeRoot with normal GC? I'm beginning to wonder if 
> > I'm calling for something different than other people are.
> > 
> > What I'm thinking of would have zero effect on the generated code, the 
> > only effect it would have is to cause an error when some code would 
> > normally attempt to invoke the GC.
> 
> It's much more complicated than that. What if a library returns an 
> object or an array to another library?
> 
> Memory allocation strategy is a cross-cutting concern.

Optional GC is in Objective-C already and it works great! 

NB: In this context by GC I mean automatic mark-sweep garbage collection and *not* refcouting. I'm ignoring here Cocoa's retain/release, because it's not directly relevant.

There are 3 options:

-no-gc. Like pure C - explicit manual memory management is used exclusively. Can't talk to GC code at all. (I don't recommend that for D).

-gc-supported. Program's memory is not garbage collected, but the program is able to talk to GCd OS and libraries. You use manual memory management, but compiler inserts write barriers and other stuff needed for seamless mixing with GCd pointers. (I imagine that'd be D's -nogc).

-gc-only. Like D (-gc-supported code looks like C from D's perspective).