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

On Wednesday, 12 February 2014 at 01:07:04 UTC, Mike wrote:
> I'm in favor of adding compiler switches like -fno-rtti, -fno-moduleinfo, -fno-exceptions etc...,

One other switch which would be useful would be -fsingle-threaded.  This would mean TLS variables could be treated as __gshared automatically.

Mike

On 12 February 2014 05:43, Walter Bright <newshound2@digitalmars.com> 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?)
>

D-- ;)

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?
>

It's only of interest to me in the sense that D might be able to infiltrate
existing C codebases. And in practical reality, I just don't see that
happening regardless.
Most C codebases I have come in contact with are still C codebases because
they require access to an immense number of target platforms/compilers, and
D-- would never be able to integrate with all those targets, which means
use of D-- alongside C would interfere with the portability of the original
code.

Personally, I don't want D--, I want D.
I may use D-- on a microprocessor or something, it could find a good home
there. But wouldn't it be better to just focus on the ability for D to
link-strip any code relating to those features you list above if it turns
out that they aren't referenced at all by the app? D should be able to
properly eliminate everything that's not actually used by the app.
I guess the flag is still useful to catch errors where a user attempting to
avoid those items hits one by mistake.

On 12 February 2014 07:11, Walter Bright <newshound2@digitalmars.com> wrote:

> On 2/11/2014 11:43 AM, Walter Bright wrote:
>
>> (First off, I hate the name "better C", any suggestions?)
>>
>
> How about "EmbeddedD", though that wouldn't be entirely accurate?
>

I prefer the idea already mentioned of making a more well-defined separation of D-core (static stuff), and then the rest as a higher layer. Ie, rather than 'EmbeddeD' which suggests a _removal_ of stuff, if D existed as 2 layers, then rather than removing the top layer, you're simply not adding the top layer. If that makes sense.

On Wednesday, 12 February 2014 at 02:18:09 UTC, Manu wrote:

> I prefer the idea already mentioned of making a more well-defined
> separation of D-core (static stuff), and then the rest as a higher layer.
> Ie, rather than 'EmbeddeD' which suggests a _removal_ of stuff, if D
> existed as 2 layers, then rather than removing the top layer, you're simply
> not adding the top layer. If that makes sense.

An Excellent Idea!

On 12 February 2014 07:12, Frank Bauer <y@z.com> wrote:

> Excellent idea. All the cries (including mine) for a non-GC D
> would stop at once.


No they wouldn't. This is not what I'm asking for in any of my posts. This is almost exclusively useful in tiny-embedded environments (ie, microcontrollers).


Instead, we could focus on gradually bringing
> all the remaining features of D-Full into D-Core over the next years. Walter would have to judge on that, but to an outsider it looks doable without too much resources.
>
> And, as I firmly believe, this could make the difference between D getting accepted by the C++ crowd on one side and D disappearing from the scene as just another C# / Java clone (untrue, but I talk about public perception).
>

I don't actually think this is what the 'no GC' crowd want. C++ programmers will not be satisfied with this. They'll see it as a step backwards towards C, not forwards.

On Wednesday, 12 February 2014 at 02:23:04 UTC, Manu wrote:
> On 12 February 2014 07:12, Frank Bauer <y@z.com> wrote:
>
>> Excellent idea. All the cries (including mine) for a non-GC D
>> would stop at once.
>
>
> No they wouldn't. This is not what I'm asking for in any of my posts.
> This is almost exclusively useful in tiny-embedded environments (ie,
> microcontrollers).
>
>
> Instead, we could focus on gradually bringing
>> all the remaining features of D-Full into D-Core over the next
>> years. Walter would have to judge on that, but to an outsider it
>> looks doable without too much resources.
>>
>> And, as I firmly believe, this could make the difference between
>> D getting accepted by the C++ crowd on one side and D
>> disappearing from the scene as just another C# / Java clone
>> (untrue, but I talk about public perception).
>>
>
> I don't actually think this is what the 'no GC' crowd want. C++ programmers
> will not be satisfied with this. They'll see it as a step backwards towards
> C, not forwards.

Seconded!

On 12 February 2014 09:06, Mike <none@none.com> wrote:

> On Tuesday, 11 February 2014 at 20:42:26 UTC, bearophile wrote:
>
>> Walter Bright:
>>
>>  (First off, I hate the name "better C", any suggestions?)
>>>
>>
>> A different name is needed.
>>
>
> I don't think a different name is needed, nor do I think it would be a good idea.  All that's needed are a few compiler switches to enable/disable features so D can be used on more platforms.  GNU g++ does this without giving it a new name (e.g. -fno-exceptions, -fno-rtti, etc...)  D can do the same without giving it a new name.


+1, I support this approach. C/C++ programmers are familiar with it, and I can imagine situations where I might want some features, but not others.

"Adam Wilson"  wrote in message news:op.xa44tcvr707hn8@invictus.hra.local...

> IIRC every class, if it inherits from nothing else, inherits from Object. The compiler expects Object on all classes. Beyond that I can't speak to how dependent the compiler is on the inheritance to make classes work.

extern(C++) classes do not depend on object/Object or anything else. 

"Manu" <turkeyman@gmail.com> wrote in message news:mailman.20.1392172483.6445.digitalmars-d@puremagic.com...
On 12 February 2014 09:06, Mike <none@none.com> wrote:

On Tuesday, 11 February 2014 at 20:42:26 UTC, bearophile wrote:
Walter Bright:

(First off, I hate the name "better C", any suggestions?)

A different name is needed.

> > I don't think a different name is needed, nor do I think it would be a good idea.  All
> > that's needed are a few compiler switches to enable/disable features so D can be
> > used on more platforms.  GNU g++ does this without giving it a new name (e.g. -fno-
> > exceptions, -fno-rtti, etc...)  D can do the same without giving it a new name.
>
> +1, I support this approach. C/C++ programmers are familiar with it, and I can
> imagine situations where I might want some features, but not others.

Having one switch does not prevent having finer-grained switches too.