Current state of "D as a better C" (Windows)?

[Frank Bauer]

@Adam: thanks for pointing out _d_newclass for me. But for 
classes I would just simply use custom allocators and 
deallocators and use new and delete as in C++.

Leaves dynamic arrays and the rest of Phobos (which parts?) which 
I have to forego if I don't like GC (but I do like slices so 
much, not much left for me to slice then ...). And no, anonymous, 
it's not just reallocating or appending to arrays, every dynamic 
array is allocated on the GC'd heap from the start.

I would really like to have something like Rust's owned pointer 
and refernce semantics in D by default:

Allocation with new gives an *owning pointer* similar to 
std.typecons.Unique, that frees its associated memory 
automatically when it goes out of scope.

Creating a *reference* from an owning pointer gives a 
'non-owning' pointer with no effect on automatic memory 
management whatsoever, but with the compiler-enforced requirement 
that its associated owning pointer can not be mutated as long as 
there are outstanding references in scope. Also the lifetime of a 
reference can not exceed the lifetime of the owning pointer it 
stems from.

This is why even a working 
(http://forum.dlang.org/thread/l96otj$tsj$1@digitalmars.com) 
std.typecons.Unique is not enough. The relationship between 
owning pointers and references needs compiler enforcement.

@Andrei: Short of dumping all GC-dependent language concepts, GC 
collection cycle times are key, no matter how little litter is 
produced. Hope the GC tracing algorithm you are implementing for 
the new custom allocators does not have to chase references too 
deep into the heap. Maybe implementing Rust-style owning pointers 
and references into the core language could turn out to be less 
time-consuming? We could still have GC around as an option a la 
GCollect!MyClass.