D as A Better C?

[Frustrated]

On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
> I've toyed with this idea for a while, and wondered what the 
> interest there is in something like this.
>
> The idea is to be able to use a subset of D that does not 
> require any of druntime or phobos - it can be linked merely 
> with the C standard library. To that end, there'd be a compiler 
> switch (-betterC) which would enforce the subset.
>
> (First off, I hate the name "better C", any suggestions?)
>
> The subset would disallow use of any features that rely on:
>
> 1. moduleinfo
> 2. exception handling
> 3. gc
> 4. Object
>
> I've used such a subset before when bringing D up on a new 
> platform, as the new platform didn't have a working phobos.
>
> What do you think?

I think the concept is great but a bit limiting if not properly
done. First:

D should have a core language subset that is essentially what you
describe above. This allows it to be used at a lower level. Call
it embedded D if you want. Other names:

D core, D*, D lite, D-, Dm, @D, D^c(D with a c superscript = D
core), etc...

Then the D we have now will be the "Closure" of the core.
Basically add in all the "cool stuff".

All the static compiler features(Templates, mixins, unit tests,
etc...) should be included in both because those are partly what
make D better than C and would actually be very cool to have on
some embedded systems(and the fact that D supports asm makes it
even cooler).

The language spec should be divided into the Static(templates,
etc...), Core, and "Closure"(since I don't have a better term).

The GC, should be completely independent though and part of a
memory management system that could be used in the core
possibly(plug and play)... not really part of the language spec.