D as A Better C?

Mike none at none.com
Tue Feb 11 17:35:06 PST 2014


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 began studying and programming in D primarily to do ARM bare
metal programming in something other than C and C++, and I want 
to comment separately on the something others have brought up on 
this thread:  Priorities.

DMD doesn't support ARM or any other embedded platform, so I 
don't know what use this would be to DMD.  If it were a front-end 
feature for GDC or LDC, yes, that would be alright, but I'm doing 
fine without it so far, and there are many other annoyances in D 
that I'd rather have fixed first.

1. There are pull requests waiting for action from people at the 
time.  Here's my own personal pet peeve

https://github.com/D-Programming-Language/dlang.org/pull/200

Andrej Mitrovic posted another list here:
http://forum.dlang.org/post/mailman.71.1391878139.21734.digitalmars-d@puremagic.com

... and I've heard so far on these is crickets.  What's the 
holdup here?

2.  The official language reference is out of date with what's 
happened in the  language.  These documents should be updated.  
Tutorials, How-To's, etc can be made by the community, but the 
core language reference should be updated an properly maintained 
by the core contributors.

3.  There were 2 separate proposals on improving the garbage 
collector for at DConf 2013, but it doesn't appear that that 
knowledge was capitalized on (as far as I know anyway).

4.  What's going on with std.allocators?

etc...

In summary:

1.  I'm not in favor of creating a subset of D.  There should be 
only one D, but it should be feature-modular.

2. I think there are some blocking obstacles in the way that are 
preventing others from getting closure and moving forward.  Those 
should be tackled first.

Mike





More information about the Digitalmars-d mailing list