My Language Feature Requests

[Craig Black]

So now that the const thing seems like it might be settled, I would like to 
put my vote in as to what features should be included next.  I can only 
think of 2 features that would be high on my priority list.  My votes go for 
the following language features that would enhance the performance of D.

1)  Adding better support for structs including ctors/dtors, inheritance, 
copy semantics, etc.  This would allow for more efficient data structures 
that perform heap allocation without relying on the GC.  Making applications 
GC-lite is fastest path to high-performance D applications.  The big reason 
I want this is that I would then be able to write an efficient array 
template that does not rely on GC.  Since I use arrays so much, this would 
provide a huge performance improvement for me.

2) Adding language features that would allow for a moving GC.  A modern, 
moving GC would also be a huge performance win.  I think we would have a 
safety problem if we currently implemented a moving GC.  Languages that have 
moving GC greatly restrict what can be done with pointers.  We need to 
provide a syntax that will allow pointers to be used when memory is 
explicitly managed, but disallow pointers for GC memory.

So, here's one idea for making D more safe for moving GC.

a) Disallow overloading new and delete for classes, and make classes 
strictly for GC, perhaps with an exception for classes instantiated on the 
stack using scope.
b) Allow new and delete to work with structs, and allocate them on the 
malloc heap.  I would still want to be able to override new and delete for 
structs, specifically to be able to use nedmalloc.

Then the compiler could disallow taking the address of a class field, since 
we know the resulting pointer would pointer to the GC heap.  Note that this 
would be a compile-time check, and so would not degrade run-time 
performance.

Another idea would be to be able to pin GC objects.  C# allows this via the 
fixed keyword.  In D, it could work like this:

a) Preceding a pointer declaration with fixed would allow that pointer to 
take the address in the GC heap.
b) Pointer arithmetic would be disallowed for fixed pointers.
c) A fixed pointer will mark the corresponding GC object as "pinned" so that 
the GC knows not to move the object.
d) When the fixed pointer is changed or deallocated, it will unpin the 
object, and pin any new object that it refers to.

The fixed pointer will have to know whether or not it points to GC memory so 
that it doesn't pin non-GC objects.  Using the first idea, we can determine 
at compile time whether a pointer points to the heap or not.

Yes, this would be a big change, but not as big as const IMO.  I feel if any 
feature warrants breaking some code, it would be high-performance GC.  But 
maybe someone else can find a solution that doesn't break compatibility.

Thoughts?

-Craig