Things that keep D from evolving?

[Chris Wright via Digitalmars-d-learn]

On Mon, 08 Feb 2016 11:22:45 +0000, thedeemon wrote:

> On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
>> What language semantics prevent precise & fast GC implementations?
> 
> easy type casting prevent precise GC.

To expand on this point:

A GC makes a tradeoff between allocating efficiently and deallocating 
efficiently. (And a compiler+runtime makes a tradeoff between generating 
larger binaries that take more time to deal with and being able to 
produce precise garbage collection.)

You can write a GC that allocates each type in its own region of memory. 
Every block has a pointer map associated with it. But this means the 
minimum allocation for each type is one page -- typically 4KB. This is 
bad for applications that have very few instances of each type and many 
types of object allocated.

A simpler thing you can do is write a GC that has two regions of memory, 
one with pointers that might point to GC memory and one without. This 
gets rid of the overhead problem but doesn't allow precise collection.

Alternatively, a language might prevent all casting, even upcasting, for 
any type that might contain pointers. Specifically:

class Foo {}
class Bar : Foo {}
Foo foo = new Bar();  // type error!

This means that the GC doesn't ever need to store the type of an 
allocated object anywhere. It can get the information it needs from a 
stack map ("pointer to Foo is stored in this stack frame at offset 8") 
and a similarly formatted map for allocated types.

It would work, but it's sufficiently constraining that I don't think 
anyone has this in a real programming language.