d future or plans for d3

[Froglegs]

> The class will still have a vptr. The vtable will contain only 
> the type info.

No way to disable type info(like in most C++ compilers you can 
disable RTTI)? I get that GC might want it, but if I disable GC 
why would I want type info?

I saw that D is planning to make the standard containers into 
classes with final methods, why do this instead of using structs 
if it bloats each instance of the container?


> Some aspects of D will _always_ require a GC or they won't 
> work. Array concatenation would be a prime example. I believe 
> that delegates are another major example. I think that scoped 
> delegates avoid the problem, but any that require closures do 
> not. Other things be done but become risky - e.g. slicing 
> arrays (the GC normally owns the memory such that all dynamic 
> arrays are slices and none of them own their memory, so slicing 
> manually managed memory gets dicey).

The array concatenation requiring GC I get, but why does a 
delegate require it?

This link says D allocates closures on the heap

http://en.wikipedia.org/wiki/Anonymous_function#D

I don't really get why, C++ lambda works well(aside from broken 
lack of template lambda's) and do not require heap usage, even 
binding it to std::function can generally avoid it if it doesn't 
exceed the  SBO size