OSNews article about C++09 degenerates into C++ vs. D discussion

[Mike Capp]

> One issue brought up is that of D "requiring" the
> use of a GC. What would it take to prove that wrong
> by making a full blown standard lib that doesn't
> use a GC, and in fact doesn't have a GC?
>
> It would be painful to work with but no more so
> than in C++. OTOH with scope() and such, it might
> be easy.

It's not just a library issue, and in some ways I think it *would* be
significantly more painful than in C++. D has a lot of innocuous-looking syntax
that allocates heap memory non-obviously; AA and dynamic array initialization
syntax, for instance. Without a GC, that's a lot of leaks and/or runtime errors
waiting to happen.

I don't think it's an impossible sell, though. It would help to have a -nogc
compiler switch or syntax attribute that disallowed usage of these constructs. And
the scope stuff is coming on nicely; if Walter extends it to support RAII member
data, as he's mentioned a few times, it'd be great.

The other big issue mentioned in the article comments is that D's GC
implementation is lacking. It's hard to say whether a language with native
pointers would really play nice with a copying collector, f'rinstance. Now that
Java is GPL it'll be interesting to see whether the JVM's GC implementation can be
yanked out for use by other languages: it's generational, copying and pretty
well-tuned.

There's some other stuff that's been buzzing around in my head about thread-local
heaps lately, but it's not coherent enough to constitute a suggestion yet.