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

[Mike]

On Thursday, 23 January 2014 at 22:39:38 UTC, Vladimir Panteleev 
wrote:
> I believe the biggest factor for why someone would want to use 
> a lighter runtime is the garbage collector. I think a lot of 
> the code in Druntime still assumes that a GC is present... and 
> then I'm not sure the D maintainers would want to maintain 
> support for such rarely-needed features such as a custom entry 
> point. (Case in point: pragma(entrypoint, symbol) has been 
> broken since DMD 2.061.)

The GC seems to be the biggest issue here, so I wanted to comment 
separately.

Each target/platform/application will have different requirements 
and those requirements will dictate the type of memory management 
implementation to use.

Ideally, I don't see why D has to be a garbage collected 
language.  Can't it be agnostic to the memory management 
implementation?

D seems to offer several options to the programmer, Scoped, 
RefCounted, new/destroy, and can even create their own garbage 
collection with the gcstub (or so I've heard).  This is great!, 
but it's not idea as it forces the programmer to change their 
idioms.  It appears that D is very tightly coupled to the memory 
management implementation, but does it need to be?

Couldn't the runtime provide some hooks that can be used by the 
runtime implementation to know when a class is instantiated, when 
it goes out of scope, when it's assigned to another reference, 
etc... and use this to provide a variety of different memory 
management implementations without the programmer having to 
change their idioms?  I'm hypothesizing that if these runtime 
hooks existed, one could create a transparent reference-counted 
implementation that would be mostly transparent to the 
programmer, for example. I still think the programmer will have 
to write code with their memory management implementation in 
mind, but they could at least stick to the same idioms.

I'm not very optimistic, but I'm hoping something like this can 
be achieved, and that's what I'm shooting for.  Absent this 
possibility, I'm not sure what to do.

I believe there is probably a GC implementation that would be 
suitable for a my target platform (ARM Cortex-M 
microcontrollers).  I can think of at least one:  Some firmware 
for microcontrollers simply need to allocate all of their objects 
at the start of the program, but have no need to free memory: 
free is the power switch.  For applications like this only 
gc.allocate() needs to be implemented, and the GC's background 
thread and gc.free() do not.  I think this would allow the 
programmer to stick with traditional D idioms, but they have to 
keep in mind gc.free() will never be and should never be called.  
Some compile-time guarantee here would be nice.

I could go on and on about some of my ideas, but I think I've 
said enough for now.  I've got a lot to learn first, anyway.

Mike