Am 11.02.2014 23:01, schrieb bearophile:
> ed:
>
>> The D compiler catches subtle bugs that creep into C code when
>> deadlines are tight and the porting itself is great as a review process.
>
> Isn't using something Clang (plus eventually a static analyzer) an even
> better strategy?
>
> Bye,
> bearophile

I also would consider it a better approach.

Even me with my C bashing, think that

clang + warnings as errors + static analyzer == C with Pascal like safety

--
Paulo

On Tuesday, 11 February 2014 at 21:41:22 UTC, Andrei Alexandrescu wrote:
> It's yet another opportunity to waste focus.

+1

On Tue, 11 Feb 2014 22:19:12 +0000, Gary Willoughby wrote:

> 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?
> 
> What will this language's niche be? What job is it targeted at? Why would somebody use better C rather than just plain C?

Here are the reasons I use D even when writing very C-style code:
 - Symbolic imports
 - Static asserts, conditional compilation, etc. that doesn't depend on a
macro language which I've never been entirely comfortable with.
 - Templates.  Also, templates.  Seriously, templates.
 - Sane type names (I'm biased on this, but I don't like "unsigned long
long" or the fact the '*' binds to the right.
 - Array types which carry length.
 - I also like to use exceptions, which I understand would not be
supported by this proposal.

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.

>
>
>> What do you think?
>
> It must produce very small binaries.
>
> If you import anything from Phobos it will not work in most cases, even if the feature you are importing does not require GC, druntime, etc, because in most cases other parts of the Phobos module use them. Is this going to cause a fragmentation of Phobos?
>
> What to do with dynamic array literals? In many cases they allocate. A partial solution is to use the [...]s syntax for fixed size array literals.
>
> Constant associative arrays at global scope don't need the GC, but they need the druntime, so I guess they too need to be disallowed.
>
> Bye,
> bearophile

I don't consider Phobos part of thE D language, just part of the D ecosystem.  If one disables features on which phobos depends, and phobos doesn't work, that's what they deserve.

In time, however, phobos could be ported to more limited systems that don't have certain D features, but that's such a long term goal right now.  I wouldn't even worry about it until the runtime is brought to those platforms first.

Mike

Le 11/02/2014 20:43, Walter Bright a écrit :
> 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?

If I correctly understand class will stay usable?
So IMO it's just like if you said : "I want do a fork of D2 without GC". If you are going to this way some people will certainly fork this D2-BetterC version and add it a new standard library more like QtCore.

In this case why not simply improve the D modularity and put features you want remove as options? The main issue is about how phobos have to manage memory, with or without GC, maybe both?

If you want go to the modularity, it's really nice, but maybe it will simpler to remove only GC and reboot phobos. Maybe it can help D contributors to be focused on system aspects of language instead of full-featured that can be reached only with a big community or commercial patterns.

On Tue, 11 Feb 2014 15:10:13 -0800, Xavier Bigand <flamaros.xavier@gmail.com> wrote:

> Le 11/02/2014 20:43, Walter Bright a écrit :
>> 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?
>
> If I correctly understand class will stay usable?
> So IMO it's just like if you said : "I want do a fork of D2 without GC". If you are going to this way some people will certainly fork this D2-BetterC version and add it a new standard library more like QtCore.
>
> In this case why not simply improve the D modularity and put features you want remove as options? The main issue is about how phobos have to manage memory, with or without GC, maybe both?
>
> If you want go to the modularity, it's really nice, but maybe it will simpler to remove only GC and reboot phobos. Maybe it can help D contributors to be focused on system aspects of language instead of full-featured that can be reached only with a big community or commercial patterns.
>

Classes rely on Object. It's better C, not C++. You'll still have structs.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator

On 11/02/14 20:43, Walter Bright wrote:
> (First off, I hate the name "better C", any suggestions?)

In no particular order:

   -minimal
   -minimal-language
   -lite
   -light
   -lightweight

FWIW I'm not sure I agree with the concerns about lost focus.  It should be a small change in and of itself, and it shouldn't be disruptive to anyone's current projects.  What it could do however is open up (or at least publicize) opportunities for people whose use-cases aren't currently perceived as well-supported.

On Tuesday, 11 February 2014 at 21:11:15 UTC, Walter Bright 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 program ONLY embedded systems in D and I very much dislike the idea of introducing a new name.  There should be only one D , but there's no reason features couldn't be enabled/disabled with compiler switches (-fno-exceptions, -fno-rtti)

There's no reason to aggregate compiler switches into a single name.  I f users want no exceptions, no gc, no objects, etc... then they should add -fno-exceptions, -fno-gc, -fno-objects, etc... to their compiler flags.

Please, I beg you! No new names. Please don't fragment the language.  Just make it a little more modular.

Mike

On Tuesday, 11 February 2014 at 22:11:30 UTC, eles wrote:
> On Tuesday, 11 February 2014 at 21:11:15 UTC, Walter Bright 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?
>
> -metal

cool, but no!

Le 12/02/2014 00:12, Adam Wilson a écrit :
> On Tue, 11 Feb 2014 15:10:13 -0800, Xavier Bigand
> <flamaros.xavier@gmail.com> wrote:
>
>> Le 11/02/2014 20:43, Walter Bright a écrit :
>>> 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?
>>
>> If I correctly understand class will stay usable?
>> So IMO it's just like if you said : "I want do a fork of D2 without
>> GC". If you are going to this way some people will certainly fork this
>> D2-BetterC version and add it a new standard library more like QtCore.
>>
>> In this case why not simply improve the D modularity and put features
>> you want remove as options? The main issue is about how phobos have to
>> manage memory, with or without GC, maybe both?
>>
>> If you want go to the modularity, it's really nice, but maybe it will
>> simpler to remove only GC and reboot phobos. Maybe it can help D
>> contributors to be focused on system aspects of language instead of
>> full-featured that can be reached only with a big community or
>> commercial patterns.
>>
>
> Classes rely on Object. It's better C, not C++. You'll still have structs.
>
Object isn't only for runtime type info and others basics properties of classes?