On 2/11/14, 15:44, Vladimir Panteleev wrote:
> On Tuesday, 11 February 2014 at 21:28:15 UTC, Peter Alexander wrote:
>> On Tuesday, 11 February 2014 at 21:22:40 UTC, Walter Bright wrote:
>>> snip
>>
>> Thank you, so this project would need to be maintained alongside D2
>> development, just like D1 was.
>>
>> Is it really worth taking effort away from D2 when so much is left to
>> do there?
>
> A few if() blocks and some code to parse a command-line option is hardly
> a "project" that needs to be "maintained alongside D2 development".
>
> However, I agree that there are better things the core compiler
> maintainers could do with their time. I think such a switch would be
> easy enough to implement and maintain by whoever needs it.

It does overlap with another suggestion however, the no gc crowd and -nogc.

I'd think if you can disable gc through -betterC, then it would be trivial to satisfy the no gc crowd as well.

Bu then again I don't really know.

On 2/11/14, 17:15, Mike 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?
>
> 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


I agree, if this is strictly restricting the language to a core subset, then I cant see it having any effect.  If you don't like it don't use it.

On Wed, 12 Feb 2014 11:30:30 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 2/12/14, 7:40 AM, Sean Kelly wrote:
>> This would certainly be a useful feature to have when porting, and
>> Walter clearly uses it himself.  Assuming this can be done with minimal
>> work, I'd say make it a DMD thing rather than a D thing in general.
>> Like -profile.  And add a switch to enable it in the front-end if
>> possible.  Then DMD (and potentially the other compilers) will have the
>> feature in case anyone finds it useful and we can move on.  Call it
>> -minimal.
>>
>> I have a feeling we've already spent more time talking about this than
>> Walter would have spent implementing it anyway, so it's already taking
>> time away from other things.  Let's just give it a nod and move on.
>
> I convinced Walter of my view on this, so he won't work on it. I trust that at least between the two of us we can focus on working on what matters most first.

Anyone else wish to take this up? I think pull requests would be welcome.

-Steve

On Thursday, 13 February 2014 at 06:51:37 UTC, 1100110 wrote:
> On 2/11/14, 17:15, Mike 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?
>>
>> 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
>
>
> I agree, if this is strictly restricting the language to a core subset, then I cant see it having any effect.  If you don't like it don't use it.

And this is the crux of the problem. For some, any change is bad
because they are happy and do not care about the rest. Simply
drawing a imaginary boundary inside d and labeling it "the core"
isn't much of a change... unless you hate change. (we can talk
about what to do with the core all day long but it is irrelevant
if we can't even draw the boundary because it freaks people out
and give them hemorrhoids and hard palpitations)

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?

-no-moduleinfo
-no-exceptions
-no-gc
-no-object

There is absolutely NO need to give any name to that beast.
Otherwise, it's an excellent idea!
You could still use classes e.g. with C++ linkage.

On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
> The subset would disallow use of any features that rely on:

I found it manageable to write bare metal code with stock LDC and no additional options. It doesn't require C runtime, malloc is only 6 lines and returns ubyte[] already. LDC actually had -noruntime option, which was only getting in the way. Some functions from druntime are useful, e.g. _d_array_cast_len, which allows simple casting between different types of buffers.

> 1. moduleinfo

I use bounds checks, and they call _d_array_bounds, which takes ModuleInfo as a parameter. How it would work?

> 2. exception handling

I think asserts are sort of useful.

> 4. Object

I didn't try to use objects without GC, but don't see any particular issue.

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

Not urgent: LDC already allows me to use D without druntime, phobos and C library.

On Thursday, 13 February 2014 at 18:07:00 UTC, inout wrote:
> -no-moduleinfo
> -no-exceptions
> -no-gc
> -no-object
>
> There is absolutely NO need to give any name to that beast.
> Otherwise, it's an excellent idea!
> You could still use classes e.g. with C++ linkage.

I've been waiting for these features in D for such a long time! I really hope that finally it will be possible to use D for osdev, embedded programming, drivers, kernel modules, high performant games and etc without struggling with druntime and phobos!

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 this is a good idea, and I believe a good result can come up from some further brainstorming.

A new, potential name for it: Diny (made from "D" and "tiny", pronounced similar to "deeny")

I would, however, rather have a normal D compiler being able to completely disable GC, exception handling, etc. However, I think it may be good to have modules...

On Thursday, 13 February 2014 at 18:38:20 UTC, Kagamin wrote:
> I use bounds checks, and they call _d_array_bounds, which takes ModuleInfo as a parameter. How it would work?

I think it is a mistake for it to take ModuleInfo at all. Those arguments should be removed entirely.

Am 13.02.2014 19:06, schrieb inout:
> 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?
>
> -no-moduleinfo
> -no-exceptions
> -no-gc
> -no-object
>
> There is absolutely NO need to give any name to that beast.
> Otherwise, it's an excellent idea!
> You could still use classes e.g. with C++ linkage.

Can we also get a build tool that produces all combinations for libraries distributed in binary form?

--
Paulo