www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D as A Better C?

reply Walter Bright <newshound2 digitalmars.com> writes:
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?
Feb 11 2014
next sibling parent "Meta" <jared771 gmail.com> writes:
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?


It'd probably be good for embedded programming, but this looks 
almost like a different language to me... I don't know if such 
fragmentation is a good idea (though I suppose we do already have 
the -betterC switch).
Feb 11 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 11 Feb 2014 14:43:02 -0500, 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?)


-cruntime


 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 it is a very good idea. I think an allocator that wraps malloc  
would be appropriate at least, since malloc calls are so clunky and  
verbose.

-Steve
Feb 11 2014
prev sibling next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:

 What do you think?


I think it would have little benefit and would just lead to 
pointless fragmentation and maintenance for the compiler devs.
Feb 11 2014
parent reply "Frustrated" <c1514843 drdrb.com> writes:
On Tuesday, 11 February 2014 at 19:56:11 UTC, Peter Alexander
wrote:

 On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright 
 wrote:

 What do you think?


 I think it would have little benefit and would just lead to 
 pointless fragmentation and maintenance for the compiler devs.


Do you program on embedded systems? If not then do you think you
are qualified to say it would have little benefit or not?

Obviously if all you ever drink is milk then water, coffee, coke,
etc.. have little benefit for you. It clearly does not mean all
those other things are useless to everyone else.

If done properly it would actually enhance D development by
partitioning it into sections while also providing a foundation
for D while expanding it's user base.
Feb 11 2014
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Tuesday, 11 February 2014 at 20:02:37 UTC, Frustrated wrote:

 On Tuesday, 11 February 2014 at 19:56:11 UTC, Peter Alexander
 wrote:

 On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright 
 wrote:

 What do you think?


 I think it would have little benefit and would just lead to 
 pointless fragmentation and maintenance for the compiler devs.


 Do you program on embedded systems? If not then do you think you
 are qualified to say it would have little benefit or not?


I do program on embedded systems.

I'll elaborate more on why I think this is a bad idea.

First, we are struggling immensely as it is to get D2 into a 
complete state. Many parts of the language are still poorly 
defined and even more poorly implemented. The standard library is 
still lacking in critical areas and there are still thousands of 
non-trivial bugs in the database. The language itself is still 
evolving rapidly. Speaking optimistically, I think we are still a 
few years away from resolving the existing language issues, based 
on the current pace of things.

We're heading in the right direction now and even accelerating, 
but I think it would be incredibly unwise to embark on a new 
side-project, which would just consume dev time, pulling effort 
away from D2 development. D1 was discontinued to spend more time 
on D2, not to start new projects of debatable benefit.

Please let's finish this language before we start on another.
Feb 11 2014
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 11 Feb 2014 15:47:12 -0500, Peter Alexander  
<peter.alexander.au gmail.com> wrote:


 I do program on embedded systems.

 I'll elaborate more on why I think this is a bad idea.

 First, we are struggling immensely as it is to get D2 into a complete  
 state. Many parts of the language are still poorly defined and even more  
 poorly implemented. The standard library is still lacking in critical  
 areas and there are still thousands of non-trivial bugs in the database.  
 The language itself is still evolving rapidly. Speaking optimistically,  
 I think we are still a few years away from resolving the existing  
 language issues, based on the current pace of things.


But the feature would be very simple to implement. You just avoid  
outputting any runtime type info, and avoid any compiler hooks into the  
runtime.

There is no requirement to do anything else. The language is finished. C's  
standard library becomes the standard library.


 We're heading in the right direction now and even accelerating, but I  
 think it would be incredibly unwise to embark on a new side-project,  
 which would just consume dev time, pulling effort away from D2  
 development. D1 was discontinued to spend more time on D2, not to start  
 new projects of debatable benefit.

 Please let's finish this language before we start on another.


I think you overestimate the size of this project.

-Steve
Feb 11 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/11/2014 12:53 PM, Steven Schveighoffer wrote:

 I think you overestimate the size of this project.


I agree it's not a big deal. It's just implementing a switch that disables a 
list of features. The switch even already exists, though it is incomplete.

The payoff is the embedded market is huge, and this can greatly expand D's 
presence in the marketplace.
Feb 11 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/14, 1:10 PM, Walter Bright wrote:

 On 2/11/2014 12:53 PM, Steven Schveighoffer wrote:

 I think you overestimate the size of this project.


 I agree it's not a big deal. It's just implementing a switch that
 disables a list of features. The switch even already exists, though it
 is incomplete.

 The payoff is the embedded market is huge, and this can greatly expand
 D's presence in the marketplace.


It's yet another opportunity to waste focus. (But then it goes to prove 
that everybody does what they want...)

Andrei
Feb 11 2014
next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 2/11/14, 3:41 PM, Andrei Alexandrescu wrote:

 On 2/11/14, 1:10 PM, Walter Bright wrote:

 On 2/11/2014 12:53 PM, Steven Schveighoffer wrote:

 I think you overestimate the size of this project.


 I agree it's not a big deal. It's just implementing a switch that
 disables a list of features. The switch even already exists, though it
 is incomplete.

 The payoff is the embedded market is huge, and this can greatly expand
 D's presence in the marketplace.


 It's yet another opportunity to waste focus. (But then it goes to prove
 that everybody does what they want...)

 Andrei


It's analogous to estimating the cost of any other new feature.  It's 
far more than the cost of just the implementation.

I don't disagree with doing it, not at all, but also have a concern with 
under estimating the costs.
Feb 11 2014
prev sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Tuesday, 11 February 2014 at 21:41:22 UTC, Andrei Alexandrescu 
wrote:

 It's yet another opportunity to waste focus.


+1
Feb 11 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:


 I think you overestimate the size of this project.


The "project" is very small as long as people don't start 
creating (or modifying) library modules for such language subset.

Bye,
bearophile
Feb 11 2014
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 11 Feb 2014 21:12:12 +0000
schrieb "bearophile" <bearophileHUGS lycos.com>:


 Steven Schveighoffer:
 

 I think you overestimate the size of this project.


 
 The "project" is very small as long as people don't start 
 creating (or modifying) library modules for such language subset.
 
 Bye,
 bearophile


Well, the idea was not to use druntime and Phobos, so no code
has to be modified there other than to allow stripping down D.
Any new library has to be written by the embedded guys :)

It could serve to check the basic language features against
the realities of the embedded market early on. </wild_guess>

-- 
Marco
Feb 17 2014
prev sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Tuesday, 11 February 2014 at 20:53:06 UTC, Steven 
Schveighoffer wrote:

 But the feature would be very simple to implement. You just 
 avoid outputting any runtime type info, and avoid any compiler 
 hooks into the runtime.

 There is no requirement to do anything else. The language is 
 finished. C's standard library becomes the standard library.


And how do people find out about this language? Won't it need to 
be documented on the website? Where does that come from?

Will this be a separate project, or just the DMD compiler with 
BETTER_C defines to mask out runtime hooks? If it's a separate 
project, who's doing all the bug fix integrations from D2 proper 
to better C? If it's the same project, who fixes the bugs when a 
runtime hook is accidentally introduced by a dev that forgot 
better C existed?

Who manages the releases of better C?

If this proves to be popular, do you really think there will be 
no feature requests? (and if it's not popular, why do it in the 
first place?)

Remember, D1 was just D2 without a bunch of features and we had 
to discontinue that because it was taking too much time to 
maintain. How will this be different?
Feb 11 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/11/2014 1:13 PM, Peter Alexander wrote:

 And how do people find out about this language? Won't it need to be documented
 on the website? Where does that come from?


It'll be documented on the website.



 Will this be a separate project,


No. It's nothing more than a switch to the compiler. No separate project.



 If it's the same project, who fixes
 the bugs when a runtime hook is accidentally introduced by a dev that forgot
 better C existed?


A bugzilla entry, just as now. No change in procedure.



 Who manages the releases of better C?


No difference, it would not be separately released.



 Remember, D1 was just D2 without a bunch of features and we had to discontinue
 that because it was taking too much time to maintain. How will this be
different?


It won't be a separate project or a separate codebase.
Feb 11 2014
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
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?
Feb 11 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/11/2014 1:28 PM, Peter Alexander wrote:

 Is it really worth taking effort away from D2 when so much is left to do there?


The "worth it" issue is does it expand the user base of D relative to the 
effort? I'd say yes.
Feb 11 2014
parent "Chris Williams" <yoreanon-chrisw yahoo.co.jp> writes:
I'd say that "D as a Better C++" would have merit. Those would 
wanted to avoid classes could do so, so you'd have already 
achieved "D as a Better C" by doing it, without having to product 
a different language reference. Point in fact, there shouldn't be 
any difference in the language references other than that in the 
GC-less variant, you have to call "delete" to free memory, do 
some extra magic to work with ranges, and Phobos isn't included.
Feb 11 2014
prev sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
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.
Feb 11 2014
parent 1100110 <0b1100110 gmail.com> writes:
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.
Feb 12 2014
prev sibling next sibling parent "Xinok" <xinok live.com> writes:
On Tuesday, 11 February 2014 at 21:13:58 UTC, Peter Alexander 
wrote:

 On Tuesday, 11 February 2014 at 20:53:06 UTC, Steven 
 Schveighoffer wrote:

 But the feature would be very simple to implement. You just 
 avoid outputting any runtime type info, and avoid any compiler 
 hooks into the runtime.

 There is no requirement to do anything else. The language is 
 finished. C's standard library becomes the standard library.


 Who manages the releases of better C?


If there is indeed a market for it, then new talent will join the 
community and contribute to the project. If not, then it will 
become a poorly maintained and unsupported feature which is 
eventually stripped from the compiler due to lack of use.

An interesting statistic on the Linux kernel:
An analysis of the Linux kernel showed 75 percent of the code 
from December 2008 to January 2010 was developed by programmers 
working for corporations, leaving about 18 percent to volunteers 
and 7% unclassified.
https://en.wikipedia.org/wiki/Linux#Community

I don't know of many people who do embedded programming for 
personal reasons. The majority of interest stems from 
corporations, not individuals. And that's where we'll find 
maintainers for this project.
Feb 11 2014
prev sibling parent "ed" <growlercab gmail.com> writes:
On Tuesday, 11 February 2014 at 21:13:58 UTC, Peter Alexander 
wrote:
[snip]

 Remember, D1 was just D2 without a bunch of features and we had 
 to discontinue that because it was taking too much time to 
 maintain. How will this be different?


It is different because this D-core is the one D-core of D2 used 
in D-runtime and Phobobs. It is simply a subset of the D2 core 
language and not a mini-D developed in parallel.

I think it would be useful in the embedded world especially. It 
may also help shrink Phobos down to be as small as possible and 
avoid the GC where it is important.

Anyway, that's my take on the proposal.

Cheers,
ed
Feb 11 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/14, 12:47 PM, Peter Alexander wrote:

 On Tuesday, 11 February 2014 at 20:02:37 UTC, Frustrated wrote:

 On Tuesday, 11 February 2014 at 19:56:11 UTC, Peter Alexander
 wrote:

 On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:

 What do you think?


 I think it would have little benefit and would just lead to pointless
 fragmentation and maintenance for the compiler devs.


 Do you program on embedded systems? If not then do you think you
 are qualified to say it would have little benefit or not?


 I do program on embedded systems.

 I'll elaborate more on why I think this is a bad idea.

 First, we are struggling immensely as it is to get D2 into a complete
 state. Many parts of the language are still poorly defined and even more
 poorly implemented. The standard library is still lacking in critical
 areas and there are still thousands of non-trivial bugs in the database.
 The language itself is still evolving rapidly. Speaking optimistically,
 I think we are still a few years away from resolving the existing
 language issues, based on the current pace of things.

 We're heading in the right direction now and even accelerating, but I
 think it would be incredibly unwise to embark on a new side-project,
 which would just consume dev time, pulling effort away from D2
 development. D1 was discontinued to spend more time on D2, not to start
 new projects of debatable benefit.

 Please let's finish this language before we start on another.


I agree. Walter, let's put that on the backburner. Thanks.

Andrei
Feb 11 2014
parent reply "Frustrated" <c1514843 drdrb.com> writes:
On Tuesday, 11 February 2014 at 21:39:19 UTC, Andrei Alexandrescu
wrote:

 On 2/11/14, 12:47 PM, Peter Alexander wrote:

 On Tuesday, 11 February 2014 at 20:02:37 UTC, Frustrated wrote:

 On Tuesday, 11 February 2014 at 19:56:11 UTC, Peter Alexander
 wrote:

 On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright 
 wrote:

 What do you think?


 I think it would have little benefit and would just lead to 
 pointless
 fragmentation and maintenance for the compiler devs.


 Do you program on embedded systems? If not then do you think 
 you
 are qualified to say it would have little benefit or not?


 I do program on embedded systems.

 I'll elaborate more on why I think this is a bad idea.

 First, we are struggling immensely as it is to get D2 into a 
 complete
 state. Many parts of the language are still poorly defined and 
 even more
 poorly implemented. The standard library is still lacking in 
 critical
 areas and there are still thousands of non-trivial bugs in the 
 database.
 The language itself is still evolving rapidly. Speaking 
 optimistically,
 I think we are still a few years away from resolving the 
 existing
 language issues, based on the current pace of things.

 We're heading in the right direction now and even 
 accelerating, but I
 think it would be incredibly unwise to embark on a new 
 side-project,
 which would just consume dev time, pulling effort away from D2
 development. D1 was discontinued to spend more time on D2, not 
 to start
 new projects of debatable benefit.

 Please let's finish this language before we start on another.


 I agree. Walter, let's put that on the backburner. Thanks.

 Andrei


I believe this is the wrong way to think about it. It is not
creating a new language, creating new features, or anything. It
is simply partitioning the language feature set into two parts,
one that works on more systems, is easier to implement by others,
easier on the compiler, debuggers, and whole tool chain and
requires virtually nothing but a little time going over the d
language spec and saying "This goes goes in this bin, that goes
in that bin" then have it reviewed.

This is really at this point just saying what the core part of
the spec is. Which is a subset of the language spec, nothing new,
very little work to be done, opens up the floodgates for people
to get it moving. It's actually counterproductive to hold it off
as you are putting the breaks on D becoming used by more people.

If you create an embedded systems level core(which is just saying
that it works well in embedded systems, which generally require
lower overhead) now then people can get it moving now.

You don't even need a compiler for it at this point. Just create
the subset language spec(easy peasy), put it out there, get some
interest on it, then let others write it for you(by forking the
compiler, making the changes that are require(which is removing
code rather than adding in most cases)).


If you wait 5 years for this then that puts D 5 years behind in
the embedded systems and 5 years that people could have been
working on it.
Feb 11 2014
parent Brad Roberts <braddr puremagic.com> writes:
On 2/11/14, 3:54 PM, Frustrated wrote:

 I believe this is the wrong way to think about it. It is not
 creating a new language, creating new features, or anything. It
 is simply partitioning the language feature set into two parts,
 one that works on more systems, is easier to implement by others,
 easier on the compiler, debuggers, and whole tool chain and
 requires virtually nothing but a little time going over the d
 language spec and saying "This goes goes in this bin, that goes
 in that bin" then have it reviewed.

 This is really at this point just saying what the core part of
 the spec is. Which is a subset of the language spec, nothing new,
 very little work to be done, opens up the floodgates for people
 to get it moving. It's actually counterproductive to hold it off
 as you are putting the breaks on D becoming used by more people.

 If you create an embedded systems level core(which is just saying
 that it works well in embedded systems, which generally require
 lower overhead) now then people can get it moving now.

 You don't even need a compiler for it at this point. Just create
 the subset language spec(easy peasy), put it out there, get some
 interest on it, then let others write it for you(by forking the
 compiler, making the changes that are require(which is removing
 code rather than adding in most cases)).


 If you wait 5 years for this then that puts D 5 years behind in
 the embedded systems and 5 years that people could have been
 working on it.


That's a very incomplete view of the work required.  If it's a formal 
part of the design of the language, then it requires far more than just 
a tiny bit of compiler work.  It requires a rework of the docs, and not 
just a tiny rework.

If all we do is a surface level execution, we'll have only muddied up 
the spec and the language even further, not clarified and simplified 
anything.  This is a recurring problem with almost every change to D. 
It's maybe half executed on.  And this would be conceptually a very 
large split, even if small at the compiler level.
Feb 11 2014
prev sibling next sibling parent reply "Frustrated" <c1514843 drdrb.com> writes:
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.
Feb 11 2014
parent reply "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 11 February 2014 at 19:59:26 UTC, Frustrated wrote:

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


How'd you overlook D--? :P
Feb 11 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/11/2014 12:56 PM, Brad Anderson wrote:

 How'd you overlook D--? :P


 From a positioning perspective, having a "less" implication is not good.
Feb 11 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/11/14, 12:56 PM, Brad Anderson wrote:

 On Tuesday, 11 February 2014 at 19:59:26 UTC, Frustrated wrote:

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


 How'd you overlook D--? :P


No new name please. It would be among the worst things to do right now.

Andrei
Feb 11 2014
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Tue, 11 Feb 2014 11:43:02 -0800, 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?)

 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 see this as a very good idea. It would make bootstrapping the language  
to new architectures or compiler backends much simpler. It would make the  
embedded/real-time folks happy. Then we could use that subset to create a  
Phobos-Core subset that worked on D-Core and could be trivially ported  
onto any new platform that has the C standard library.

I don't see the complexity argument as relevant. If properly designed such  
that the Core has absolutely no requirement on higher level features then  
all you're doing is building the higher level features on the "library" of  
Core features. We all do this kind of thing every day. :-)

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
Feb 11 2014
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11-Feb-2014 23:43, Walter Bright Đ¿Đ¸ÑˆĐµÑ‚:

 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 kind of like it. What about TLS?
Would make a nice subset for embedded programming. Obviously needs its 
own library (friendlier memory allocation etc.), preferably later on 
integrated as a subset of Phobos.

-- 
Dmitry Olshansky
Feb 11 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/11/2014 12:37 PM, Dmitry Olshansky wrote:

 I kind of like it. What about TLS?


TLS would be dependent on whether the target system supported it for C or not.


 Would make a nice subset for embedded programming. Obviously needs its own
 library (friendlier memory allocation etc.), preferably later on integrated as
a
 subset of Phobos.


The idea is it would not require any library other than the C runtime.
Feb 11 2014
parent "Steve Teale" <steve.teale britseyeview.com> writes:
On Tuesday, 11 February 2014 at 21:13:56 UTC, Walter Bright wrote:

 On 2/11/2014 12:37 PM, Dmitry Olshansky wrote:

 The idea is it would not require any library other than the C 
 runtime.


This somehow reminds me of the first C++ compiler, which 
generated C.

I quite like the idea.

Steve
Feb 12 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


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


A different name is needed.



 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
Feb 11 2014
parent reply "Mike" <none none.com> writes:
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
Feb 11 2014
parent reply Manu <turkeyman gmail.com> writes:
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.



 Feb 11 2014



  parent  "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"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. 



 Feb 11 2014



prev sibling next sibling parent  Paulo Pinto <pjmlp progtools.org>  writes:


Am 11.02.2014 20:43, schrieb Walter Bright:

 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?


That looks a nice idea.

Yeah, "better C" is already owned by C++. :)

--
Paulo



 Feb 11 2014



prev sibling next sibling parent reply "Brian Rogoff" <brogoff gmail.com>  writes:


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?


Which D metaprogramming (templates, mixins, ctfe, ..) features 
would be in this D subset?

Would the non-gc'ed functional programming features (downward 
funargs) be in the subset?

If the answers are "all and yes" I'd be very interested, if "none 
and no" then much less interested. Please say more about which 
features you expect to make the cut.

D-lite, while already used, is the natural name choiec.

As others point out, there's some risk of fragmentation, but 
there's precedent even in unsubsettable languages like Ada 
(SPARK) so I don't think the risk is so great.

-- Brian



 Feb 11 2014



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 2/11/2014 1:00 PM, Brian Rogoff wrote:

 Which D metaprogramming (templates, mixins, ctfe, ..) features would be in this
 D subset?


All of them.



 Would the non-gc'ed functional programming features (downward funargs) be in
the
 subset?


All of them.



 If the answers are "all and yes" I'd be very interested, if "none and no" then
 much less interested. Please say more about which features you expect to make
 the cut.


Associative arrays would not, as they rely on the GC.

It would require support for COMDATs from the linker, while C does not. 
Fortunately, C++ adoption has pretty much driven COMDAT support into all the 
linkers that matter.



 D-lite, while already used, is the natural name choiec.


Cute names are amusing for a few seconds, but they get old real fast.



 As others point out, there's some risk of fragmentation, but there's precedent
 even in unsubsettable languages like Ada (SPARK) so I don't think the risk is
so
 great.


There's also precedent in C itself, as the C Standard codifies the notion of a 
"freestanding" implementation of C, although that's not quite what we're
talking 
about here. Freestanding means no C runtime library, either.



 Feb 11 2014



  parent reply "Nicolas Sicard" <dransic gmail.com>  writes:


On Tuesday, 11 February 2014 at 21:19:36 UTC, Walter Bright wrote:

 On 2/11/2014 1:00 PM, Brian Rogoff wrote:

 Which D metaprogramming (templates, mixins, ctfe, ..) features 
 would be in this
 D subset?


 All of them.


And would all of D features be available at compile time?
CTFE/string mixins seem to be rather limited if features relying
on the GC are excluded.



 Feb 12 2014



  parent  "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Nicolas Sicard"  wrote in message 
news:pvmgtktejwykqpibzvjc forum.dlang.org...

 Which D metaprogramming (templates, mixins, ctfe, ..) features would be 
 in this
 D subset?


 All of them.


And would all of D features be available at compile time?
CTFE/string mixins seem to be rather limited if features relying
on the GC are excluded.


Yes.  The limits would only apply to things used at runtime. 



 Feb 12 2014



prev sibling next sibling parent  "Tove" <tove fransson.se>  writes:


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?


It's a Delightful(dlite?) idea, I long considered doing something 
like this as it would facilitate using D at work.



 Feb 11 2014



prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


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?



 Feb 11 2014



 next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Tue, 11 Feb 2014 16:11:19 -0500, 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?


Sorry, WAAAY too many D's :)

-Steve



 Feb 11 2014



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 2/11/2014 1:53 PM, Steven Schveighoffer wrote:

 On Tue, 11 Feb 2014 16:11:19 -0500, Walter Bright <newshound2 digitalmars.com>

 How about "EmbeddedD", though that wouldn't be entirely accurate?


 Sorry, WAAAY too many D's :)


That's a Good Thing (tm), isn't it?



 Feb 11 2014



  parent  "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Tue, 11 Feb 2014 16:54:56 -0500, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 2/11/2014 1:53 PM, Steven Schveighoffer wrote:

 On Tue, 11 Feb 2014 16:11:19 -0500, Walter Bright  
 <newshound2 digitalmars.com>

 How about "EmbeddedD", though that wouldn't be entirely accurate?


 Sorry, WAAAY too many D's :)


 That's a Good Thing (tm), isn't it?


Not sure. That last D looks like a typo...

-Steve



 Feb 11 2014



prev sibling  parent reply "Francesco Cattoglio" <francesco.cattoglio gmail.com>  writes:


On Tuesday, 11 February 2014 at 21:53:42 UTC, Steven 
Schveighoffer wrote:

 On Tue, 11 Feb 2014 16:11:19 -0500, 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?


 Sorry, WAAAY too many D's :)

 -Steve


If you hate too many Ds, then the best name is by far "D flat": Dâ™­



 Feb 11 2014



  parent  "SomeDude" <lovelydear mailmetrash.com>  writes:


On Tuesday, 11 February 2014 at 21:55:49 UTC, Francesco Cattoglio
wrote:

 If you hate too many Ds, then the best name is by far "D flat": 
 Dâ™­


Or rather D minor.

Or what about AC ?
Cuz AC is D C.
Or Washington (D C).

EmbeD wasn't too bad. It allows "In bed with EmbeD".



 Feb 16 2014



prev sibling next sibling parent reply "eles" <eles eles.com>  writes:


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



 Feb 11 2014



  parent  "Mike" <none none.com>  writes:


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!



 Feb 11 2014



prev sibling next sibling parent reply "Mike" <none none.com>  writes:


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



 Feb 11 2014



  parent reply 1100110 <0b1100110 gmail.com>  writes:


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.



 Feb 12 2014



 next sibling parent  "Frustrated" <c1514843 drdrb.com>  writes:


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)



 Feb 13 2014



prev sibling  parent  "SomeDude" <lovelydear mailmetrash.com>  writes:


On Thursday, 13 February 2014 at 06:51:37 UTC, 1100110 wrote:

 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.


But you can't use Phobos. Practically, that would mean rewriting
a lot of Phobos, or another standard library.



 Feb 16 2014



prev sibling next sibling parent  "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Tue, 11 Feb 2014 16:11:19 -0500, 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?


What about BareD?

-Steve



 Feb 11 2014



prev sibling  parent reply Manu <turkeyman gmail.com>  writes:


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.



 Feb 11 2014



  parent  "Mike" <none none.com>  writes:


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!



 Feb 11 2014



prev sibling next sibling parent reply "Frank Bauer" <y z.com>  writes:


Excellent idea. All the cries (including mine) for a non-GC D
would stop at once. 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

(untrue, but I talk about public perception).



 Feb 11 2014



 next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net>  writes:


On 11/02/14 22:12, Frank Bauer wrote:

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


I hope so, but I doubt it.  Instead the criticisms will start focusing on the 
lack of library functionality and the potential for a Phobos/Tango style split 
between regular D and the minimal non-GC D.

That's not however a reason to not go forward with this.



 Feb 11 2014



  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Tue, 11 Feb 2014 18:39:53 -0500, Joseph Rushton Wakeling  
<joseph.wakeling webdrake.net> wrote:


 On 11/02/14 22:12, Frank Bauer wrote:

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


 I hope so, but I doubt it.  Instead the criticisms will start focusing  
 on the lack of library functionality and the potential for a  
 Phobos/Tango style split between regular D and the minimal non-GC D.


I don't think so. Any valid minimal D is valid D. Tango vs. Phobos was a  
completely different incompatible runtime, and then later, a difference  
between D1 and D2.

-Steve



 Feb 11 2014



  parent  Joseph Rushton Wakeling <joseph.wakeling webdrake.net>  writes:


On 12/02/14 00:44, Steven Schveighoffer wrote:

 I don't think so. Any valid minimal D is valid D. Tango vs. Phobos was a
 completely different incompatible runtime, and then later, a difference between
 D1 and D2.


I'm not saying it'd be _fair_ criticism.  I'm just anticipating that it'll 
happen. :-)



 Feb 11 2014



prev sibling  parent reply Manu <turkeyman gmail.com>  writes:


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

 (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.



 Feb 11 2014



 next sibling parent  "Mike" <none none.com>  writes:


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

 (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!



 Feb 11 2014



prev sibling  parent  Jerry <jlquinn optonline.net>  writes:


Manu <turkeyman gmail.com> writes:


 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.


I have to agree with this.  I was attracted to D by the better C++
possibilities.  I still want that.  And I would like to see the gc be as
performant as possible, and be relatively easy to avoid in bottlenecks.

I don't work on real time systems, but throughput and not hammering the
memory bus matters a lot.

Jerry



 Feb 13 2014



prev sibling next sibling parent reply "Xinok" <xinok live.com>  writes:


On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:

 What do you think?


I don't do embedded programming, so take my opinion with a grain 
of salt...

Rather than making this a compiler switch, I think it would be 
more beneficial to branch this off as a new project, essentially 
building a new compiler. Similarly, it would contain that subset 
of features which are practical for embedded programming and 
strip out the rest. Then likewise to VisualD, make it an 
"official" repository on GitHub.

The benefit of having a separate project dedicated to embedded 
programming is the ability to retain a standard library without 
convoluting the rest of the D ecosystem. A slim standard library 
could be developed, mimicking (or even branched from) Phobos, but 
optimized for embedded systems. As DMD is updated, the changes 
would be merged into "embedded D", but otherwise the two would be 
maintained independently of one another.

It wouldn't be too dissimilar to other projects like it. There 
are projects which add non-official extensions to other 
languages, such as adding a garbage collector to C/C++.



 Feb 11 2014



  parent  Mike Parker <aldacron gmail.com>  writes:


On 2/12/2014 6:13 AM, Xinok wrote:

 On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:

 What do you think?


 I don't do embedded programming, so take my opinion with a grain of salt...

 Rather than making this a compiler switch, I think it would be more
 beneficial to branch this off as a new project, essentially building a
 new compiler. Similarly, it would contain that subset of features which
 are practical for embedded programming and strip out the rest. Then
 likewise to VisualD, make it an "official" repository on GitHub.

 The benefit of having a separate project dedicated to embedded
 programming is the ability to retain a standard library without
 convoluting the rest of the D ecosystem. A slim standard library could
 be developed, mimicking (or even branched from) Phobos, but optimized
 for embedded systems. As DMD is updated, the changes would be merged
 into "embedded D", but otherwise the two would be maintained
 independently of one another.


One of the points is to avoid the need of a standard library. Besides, 
making a separate compiler adds more maintenance overhead and is a sure 
way to encourage fragmentation.



 Feb 11 2014



prev sibling next sibling parent  "Dicebot" <public dicebot.lv>  writes:


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 have been asking for it since long time ago :) It will 
essentially just turn linker errors into compiler errors when you 
try to hack barebone stuff which is considerably nicer. Calling 
it "embedded D" would have been a bit overly abmitious as there 
will still be some issues to be resolved but it will provider 
more convenient starting ground for those willing to experiment.



 Feb 11 2014



prev sibling next sibling parent reply "Francesco Cattoglio" <francesco.cattoglio gmail.com>  writes:


On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:

 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.

 What do you think?


I don't do embedded, so my opinion is just an opinion.

I don't see any big issue with having some extra work.
Do you think it would be easier to create this after having 
switched to "DDMD"?



 Feb 11 2014



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 2/11/2014 1:34 PM, Francesco Cattoglio wrote:

 Do you think it would be easier to create this after having switched to "DDMD"?


That wouldn't make it either harder or easier.



 Feb 11 2014



prev sibling next sibling parent reply "ed" <growlercab gmail.com>  writes:


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 a D subset language would be great.

We currently used D in a similar manner at work. Myself and a 
colleague often use D to prototype C/C++ code and then manually 
ported it across. The manual port imposes very tight constraints 
on what we can use from D but it is still better than C.

Even with the manual porting effort it speeds up development. 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.

Cheers,
ed



 Feb 11 2014



  parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


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



 Feb 11 2014



 next sibling parent reply "ed" <growlercab gmail.com>  writes:


On Tuesday, 11 February 2014 at 22:01:01 UTC, bearophile wrote:

 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


Absolutely :D

Our main focus has been to introduced D into our workplace. We've 
been converting a number of old die hard C programmers by showing 
them how much better the language is, even if one is just writing 
"C" in D. The bug catching was, however, a pleasant side-effect.

I think the transition to D in the embedded world would be 
quicker if it were possible to obtain a minimal D language that 
produces the smallest binaries possible.

Perhaps a good place to start would be with a formal grammar that 
defines what is the kernel of D and what is the D language proper.

Cheers,
ed



 Feb 11 2014



 next sibling parent  "Mike" <none none.com>  writes:


On Tuesday, 11 February 2014 at 22:21:32 UTC, ed wrote:


 Perhaps a good place to start would be with a formal grammar 
 that defines what is the kernel of D and what is the D language 
 proper.


Yes, and I think this is far more important task than the OP's 
proposal.

Mike



 Feb 11 2014



prev sibling  parent reply "Mike" <none none.com>  writes:


On Tuesday, 11 February 2014 at 22:21:32 UTC, ed wrote:

 On Tuesday, 11 February 2014 at 22:01:01 UTC, bearophile wrote:

 I think the transition to D in the embedded world would be 
 quicker if it were possible to obtain a minimal D language that 
 produces the smallest binaries possible.


How about a 56 byte hello world [1].  Small binaries are already 
possible with GDC (and maybe LDC too).  If you want structs and 
static classes, you only need a 20 line object.d file for GDC 
[2].  This is proving to be quite a suitable replacement for C in 
my current experiments.

Mike

[1] 
https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/wiki/1.1---Hello,-World!
[2] 
https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/blob/structs/source/object.d



 Feb 11 2014



  parent  Marco Leise <Marco.Leise gmx.de>  writes:


Am Wed, 12 Feb 2014 03:50:58 +0000
schrieb "Mike" <none none.com>:


 On Tuesday, 11 February 2014 at 22:21:32 UTC, ed wrote:

 On Tuesday, 11 February 2014 at 22:01:01 UTC, bearophile wrote:

 I think the transition to D in the embedded world would be 
 quicker if it were possible to obtain a minimal D language that 
 produces the smallest binaries possible.


 
 How about a 56 byte hello world [1].  Small binaries are already 
 possible with GDC (and maybe LDC too).  If you want structs and 
 static classes, you only need a 20 line object.d file for GDC 
 [2].  This is proving to be quite a suitable replacement for C in 
 my current experiments.
 
 Mike
 
 [1] 
 https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/wiki/1.1---Hello,-World!
 [2] 
 https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/blob/structs/source/object.d


That's an awesome proof of concept.

-- 
Marco



 Feb 17 2014



prev sibling  parent  Paulo Pinto <pjmlp progtools.org>  writes:


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



 Feb 11 2014



prev sibling next sibling parent reply "Gary Willoughby" <dev nomad.so>  writes:


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?



 Feb 11 2014



 next sibling parent reply "eles" <eles eles.com>  writes:


On Tuesday, 11 February 2014 at 22:19:13 UTC, Gary Willoughby 
wrote:

 On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright 
 wrote:



 What will this language's niche be? What job is it targeted at?


My job (realtime embedded Linux).


 Why would somebody use better C rather than just plain C?


If you send me to a C compiler, why bother to evangelize me D? I 


Please, stop telling about "alternatives". It is like taking 
aways D's very reason of existence.

If is just an application language, it loses. There are better 
and better-supported out there on the market.

But there is no better systems programming language.

System programming language means being able to write the 
druntime in it. Without relying on, well, druntime.

If you keep telling "you could use C for that", then, well, I 
could use C instead of D everywhere, just plain and simple, just 
as I already do today. In that case, sorry, neither me neither my 
boss, we are not interested in a Java clone. We don't have space 
for the virtual machine (oh, call it runtime...).

And, as you say, we could just use C. Or that embedded subset of 
C++. Speaking about subsets, by the way...



 Feb 11 2014



  parent  "Mike" <none none.com>  writes:


On Tuesday, 11 February 2014 at 22:25:01 UTC, eles wrote:

 Why would somebody use better C rather than just plain C?


 If you send me to a C compiler, why bother to evangelize me D? 


 Please, stop telling about "alternatives". It is like taking 
 aways D's very reason of existence.

 If is just an application language, it loses. There are better 
 and better-supported out there on the market.

 But there is no better systems programming language.


I very much agree here, but we don't need new name to make D 
suitable for systems programming. A small set of compiler 
switches will suffice.

Mike



 Feb 11 2014



prev sibling  parent  Justin Whear <justin economicmodeling.com>  writes:


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.



 Feb 11 2014



prev sibling next sibling parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:

 The subset would disallow use of any features that rely on:

 1. moduleinfo
 2. exception handling
 3. gc
 4. Object


I think this would kill the usefulness. I've written little D 
runtimes (doesn't even use the C runtime!) to build working 
programs that use this stuff and it didn't take a lot of code.

I'd prefer it if the switch ONLY suppressed generation of 
typeinfo or moduleinfo... and I think there was something else, 
we have a betterC bugzilla entry that summarized the last 
discussion.

But still, I'd say it would be better to just not generate some 
of these things and let the user deal with it. They might 
manually opt-in to certain things and might not... and I'd say go 
ahead and leave it as linker errors too.


If we want other stuff to help, do it with the whole D language, 
for example  nogc has been discussed and might be useful here, 
while also being useful with the regular druntime.



 Feb 11 2014



prev sibling next sibling parent reply Xavier Bigand <flamaros.xavier gmail.com>  writes:


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.



 Feb 11 2014



  parent reply "Adam Wilson" <flyboynw gmail.com>  writes:


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 =E9crit :

 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 struct=
s.

-- =

Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator



 Feb 11 2014



  parent reply Xavier Bigand <flamaros.xavier gmail.com>  writes:


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?



 Feb 11 2014



  parent reply "Adam Wilson" <flyboynw gmail.com>  writes:


On Tue, 11 Feb 2014 15:25:23 -0800, Xavier Bigand  =

<flamaros.xavier gmail.com> wrote:


 Le 12/02/2014 00:12, Adam Wilson a =E9crit :

 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 =E9crit :

 I've toyed with this idea for a while, and wondered what the intere=








st

 there is in something like this.

 The idea is to be able to use a subset of D that does not require a=








ny  =


 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 th=






is

 D2-BetterC version and add it a new standard library more like QtCor=






e.

 In this case why not simply improve the D modularity and put feature=






s

 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 wil=






l

 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 o=


f  =


 classes?


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.

-- =

Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator



 Feb 11 2014



  parent reply "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"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. 



 Feb 11 2014



  parent reply "Adam Wilson" <flyboynw gmail.com>  writes:


On Tue, 11 Feb 2014 18:40:08 -0800, Daniel Murphy  
<yebbliesnospam gmail.com> wrote:


 "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.


Awesome, I didn't know that. Does that mean we could add a switch for  
default linkage? That's good to know for reasons related to a couple of my  
D projects.

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



 Feb 11 2014



  parent reply "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


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


 Awesome, I didn't know that. Does that mean we could add a switch for 
 default linkage? That's good to know for reasons related to a couple of my 
 D projects.


It could be done, although I'm not sure it's a good idea. 



 Feb 11 2014



  parent reply "Adam Wilson" <flyboynw gmail.com>  writes:


On Tue, 11 Feb 2014 18:50:57 -0800, Daniel Murphy  
<yebbliesnospam gmail.com> wrote:


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


 Awesome, I didn't know that. Does that mean we could add a switch for  
 default linkage? That's good to know for reasons related to a couple of  
 my D projects.


 It could be done, although I'm not sure it's a good idea.


Why?

Well, I was asking for the D-Core folks, if they could default the linkage  
to C++ then they could use classes without Object. And setting the default  
linkage might be useful for bindings.

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



 Feb 11 2014



 next sibling parent  Manu <turkeyman gmail.com>  writes:


On 12 February 2014 12:55, Adam Wilson <flyboynw gmail.com> wrote:


 On Tue, 11 Feb 2014 18:50:57 -0800, Daniel Murphy <
 yebbliesnospam gmail.com> wrote:

  "Adam Wilson"  wrote in message news:op.xa5d17y1707hn8 

 invictus.hra.local...

  Awesome, I didn't know that. Does that mean we could add a switch for

 default linkage? That's good to know for reasons related to a couple of my
 D projects.


 It could be done, although I'm not sure it's a good idea.


 Why?

 Well, I was asking for the D-Core folks, if they could default the linkage
 to C++ then they could use classes without Object. And setting the default
 linkage might be useful for bindings.



It'll create linking problems if different modules refer to eachother, but
happen to be compiled with different flags.
It would be better to use 'extern(C):' at the top of your module, then
modules importing your module know what to expect.

extern(C++) classes are still GC allocated, so it's still not so simple.
You'd need to start using emplace with manual allocation.



 Feb 11 2014



prev sibling  parent  "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


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


 Why?

 Well, I was asking for the D-Core folks, if they could default the linkage 
 to C++ then they could use classes without Object. And setting the default 
 linkage might be useful for bindings.


Problems with overloading, separate compilation, some types can't be used 
with extern(C++) functions etc.

Just putting extern(C++): at the top of the file does a similar thing within 
the current system. 



 Feb 11 2014



prev sibling next sibling parent  Joseph Rushton Wakeling <joseph.wakeling webdrake.net>  writes:


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.



 Feb 11 2014



prev sibling next sibling parent reply "Mike" <none none.com>  writes:


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++.

I'm in favor of adding compiler switches like -fno-rtti, 
-fno-moduleinfo, -fno-exceptions etc..., but I'm not in favor of 
aggregating them under a single name like "-betterC" or "-worseD".

I use GDC with the -fno-emit-moduleinfo switch.  In fact, it is 
necessary for what I'm trying to do.  Right now I have to stub 
out the TypeInfo stuff[1] to get things to compile, so a 
-fno-rtti switch would be cool, but I still don't understand why 
the compiler doesn't just emit whatever TypeInfo stuff I supply, 
and nothing if I don't supply it.  Discussion here[2]

Automatic Memory Management should be decoupled from the language 
as much as possible.  Ideally we should just be able to add -lgc, 
-larc, -lnone to our linker flags and the language would use a 
Garbage Collector, Automatic Reference Counting, or no memory 
management respectively.  Or something along these lines.  I 
don't know what the right solution is. Just make it transparent 
to the language and an option to the programmer.  I realize this 
is easier said than done, though.

BOTTOM LINE:
I don't want a better C.  I want a better D.

[1] 
https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/blob/memory-mapped-io/source/object.d
[2] 
http://forum.dlang.org/post/jynxfglpulguvqbivrms forum.dlang.org

Mike



 Feb 11 2014



  parent  "Mike" <none none.com>  writes:


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



 Feb 11 2014



prev sibling next sibling parent reply "Mike" <none none.com>  writes:


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



 Feb 11 2014



  parent  "Dominikus Dittes Scherkl"  writes:


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.


as compiler switch I would call it according to what it does:

-noPhobos

The language itself shouldn't use a different name, if you need 
to refer to it, I'd suggest to call it "d" (small D).

I find the idea intriguing - it could be useful pretty much 
everywhere where still C is in use despite C++ exists for more 
than two decades, not to mention other languages.



 Feb 12 2014



prev sibling next sibling parent  Manu <turkeyman gmail.com>  writes:


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.



 Feb 11 2014



prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Walter Bright"  wrote in message news:lddug4$jgv$1 digitalmars.com...


 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.


Yeah, this has been on my todo list for a long time, last time it came up it 
resulting in this: https://github.com/yebblies/dmd/tree/microd

I would love to use this at work, although of course dmd does not support 
any of the architectures I need.

For all the people crying about forking the language, this will only fork 
the language as much as  safe did (ie not at all). 



 Feb 11 2014



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 2/11/14, 6:47 PM, Daniel Murphy wrote:

 "Walter Bright"  wrote in message news:lddug4$jgv$1 digitalmars.com...


 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.


 Yeah, this has been on my todo list for a long time, last time it came
 up it resulting in this: https://github.com/yebblies/dmd/tree/microd

 I would love to use this at work, although of course dmd does not
 support any of the architectures I need.


Well that should raise a question about the proper priorities.


 For all the people crying about forking the language, this will only
 fork the language as much as  safe did (ie not at all).


As I told Walter: there's this joke that goes as follows. A guy goes to 
the doctor and the doctor asks "How is your sex life?" and the guy goes, 
"Almost every day!" "How do you mean that?" "Almost on Monday, almost on 
Tuesday, almost on Wednesday..."

We almost have a working  safe, we almost have good reference counting, 
we almost have good copy construction, we almost have a working "shared" 
qualifier, we almost have a solution to NonNull, we almost have complete 
qualifier inference, and we almost have a self-hosting compiler.

Last thing we want is to add an almost working "better C" thingamaroo to 
the list.


Andrei



 Feb 11 2014



 next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com>  writes:


On Wednesday, 12 February 2014 at 04:52:00 UTC, Andrei 
Alexandrescu wrote:

 Well that should raise a question about the proper priorities.


My hope would be this would trickle down to GDC and I can use 
that.


 For all the people crying about forking the language, this 
 will only
 fork the language as much as  safe did (ie not at all).


 As I told Walter: there's this joke that goes as follows. A guy 
 goes to the doctor and the doctor asks "How is your sex life?" 
 and the guy goes, "Almost every day!" "How do you mean that?" 
 "Almost on Monday, almost on Tuesday, almost on Wednesday..."


"I only try on Wednesday"


 We almost have a working  safe, we almost have good reference 
 counting, we almost have good copy construction, we almost have 
 a working "shared" qualifier, we almost have a solution to 
 NonNull, we almost have complete qualifier inference, and we 
 almost have a self-hosting compiler.


I'm not planning to stop working on the self-hosting compiler, 
just working on the same thing constantly gets a bit boring 
eventually, and half the time I'm blocked waiting for Walter to 
approve something anyway. (Not currently!)

As for the others, I implemented most of  safe, and I don't 
really care about the rest.


 Last thing we want is to add an almost working "better C" 
 thingamaroo to the list.


 Andrei


The thing is, we do almost have it, because it's not a huge thing 
to implement.  Low hanging fruit vs long-term priorities.



 Feb 12 2014



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 2/12/14, 12:34 AM, Daniel Murphy wrote:

 The thing is, we do almost have it, because it's not a huge thing to
 implement.  Low hanging fruit vs long-term priorities.


There's this thing in psychology - when confronted with too many 
unprioritized tasks, people will consistently choose the easiest ones.

Andrei



 Feb 12 2014



  parent reply "Sean Kelly" <sean invisibleduck.org>  writes:


On Wednesday, 12 February 2014 at 16:16:10 UTC, Andrei 
Alexandrescu wrote:

 On 2/12/14, 12:34 AM, Daniel Murphy wrote:

 The thing is, we do almost have it, because it's not a huge 
 thing to
 implement.  Low hanging fruit vs long-term priorities.


 There's this thing in psychology - when confronted with too 
 many unprioritized tasks, people will consistently choose the 
 easiest ones.


Yep.  When overwhelmed, it's particularly welcome to be making 
quantifiable progress on something.  Anything.  And in many cases 
it really is worth interspersing the easy tasks with the hard 
ones just to keep morale up, even if those easy tasks are really 
not terribly important from a priorities perspective.  Of course, 
the flip-side of that is feature creep, when too much time is 
spent on the low-priority easy stuff.  I think every programmer 
needs to learn this balance at some point, as an aid to avoiding 
burnout.



 Feb 12 2014



 next sibling parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 2/12/14, 8:49 AM, Sean Kelly wrote:

 On Wednesday, 12 February 2014 at 16:16:10 UTC, Andrei Alexandrescu wrote:

 On 2/12/14, 12:34 AM, Daniel Murphy wrote:

 The thing is, we do almost have it, because it's not a huge thing to
 implement.  Low hanging fruit vs long-term priorities.


 There's this thing in psychology - when confronted with too many
 unprioritized tasks, people will consistently choose the easiest ones.


 Yep.  When overwhelmed, it's particularly welcome to be making
 quantifiable progress on something.  Anything.  And in many cases it
 really is worth interspersing the easy tasks with the hard ones just to
 keep morale up, even if those easy tasks are really not terribly
 important from a priorities perspective.  Of course, the flip-side of
 that is feature creep, when too much time is spent on the low-priority
 easy stuff.  I think every programmer needs to learn this balance at
 some point, as an aid to avoiding burnout.


There's always answering email and posting to forums :o).

Andrei



 Feb 12 2014



prev sibling  parent reply "Gary Willoughby" <dev nomad.so>  writes:


On Wednesday, 12 February 2014 at 16:49:46 UTC, Sean Kelly wrote:

 Yep.  When overwhelmed, it's particularly welcome to be making 
 quantifiable progress on something.  Anything.  And in many 
 cases it really is worth interspersing the easy tasks with the 
 hard ones just to keep morale up, even if those easy tasks are 
 really not terribly important from a priorities perspective.  
 Of course, the flip-side of that is feature creep, when too 
 much time is spent on the low-priority easy stuff.  I think 
 every programmer needs to learn this balance at some point, as 
 an aid to avoiding burnout.


Yep we need to finish and polish what we have before adding 
anything new. There are so many long term important bugs still 
not fixed. https://d.puremagic.com/issues/show_bug.cgi?id=314



 Feb 12 2014



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 2/12/14, 9:20 AM, Gary Willoughby wrote:

 On Wednesday, 12 February 2014 at 16:49:46 UTC, Sean Kelly wrote:

 Yep.  When overwhelmed, it's particularly welcome to be making
 quantifiable progress on something.  Anything.  And in many cases it
 really is worth interspersing the easy tasks with the hard ones just
 to keep morale up, even if those easy tasks are really not terribly
 important from a priorities perspective. Of course, the flip-side of
 that is feature creep, when too much time is spent on the low-priority
 easy stuff.  I think every programmer needs to learn this balance at
 some point, as an aid to avoiding burnout.


 Yep we need to finish and polish what we have before adding anything
 new. There are so many long term important bugs still not fixed.
 https://d.puremagic.com/issues/show_bug.cgi?id=314


Hasn't Kenji fixed that?

Andrei



 Feb 12 2014



prev sibling next sibling parent  Bruno Medeiros <brunodomedeiros+dng gmail.com>  writes:


On 12/02/2014 04:51, Andrei Alexandrescu wrote:

 As I told Walter: there's this joke that goes as follows. A guy goes to
 the doctor and the doctor asks "How is your sex life?" and the guy goes,
 "Almost every day!" "How do you mean that?" "Almost on Monday, almost on
 Tuesday, almost on Wednesday..."

 We almost have a working  safe, we almost have good reference counting,
 we almost have good copy construction, we almost have a working "shared"
 qualifier, we almost have a solution to NonNull, we almost have complete
 qualifier inference, and we almost have a self-hosting compiler.


Hear, hear!

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros



 Feb 19 2014



prev sibling  parent  Bruno Medeiros <brunodomedeiros+dng gmail.com>  writes:


On 12/02/2014 04:51, Andrei Alexandrescu wrote:

 As I told Walter: there's this joke that goes as follows. A guy goes to
 the doctor and the doctor asks "How is your sex life?" and the guy goes,
 "Almost every day!" "How do you mean that?" "Almost on Monday, almost on
 Tuesday, almost on Wednesday..."

 We almost have a working  safe, we almost have good reference counting,
 we almost have good copy construction, we almost have a working "shared"
 qualifier, we almost have a solution to NonNull, we almost have complete
 qualifier inference, and we almost have a self-hosting compiler.


Hear, hear!

--
Bruno Medeiros



 Feb 19 2014



prev sibling next sibling parent reply Manu <turkeyman gmail.com>  writes:


On 12 February 2014 12:11, Manu <turkeyman gmail.com> wrote:


 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.


I've changed my mind. Depending on a functional link-stripper sucks.
I think it's definitely useful, although I think it should be implemented
as a suite of flags, not just a single one. Sure, a convenience flag can be
offered, but as an implementation detail, it should be a suite of flags.



 Feb 11 2014



  parent reply "eles" <eles eles.com>  writes:


On Wednesday, 12 February 2014 at 03:28:57 UTC, Manu wrote:

 On 12 February 2014 12:11, Manu <turkeyman gmail.com> wrote:


 On 12 February 2014 05:43, Walter Bright 
 <newshound2 digitalmars.com>wrote:





 I've changed my mind. Depending on a functional link-stripper 
 sucks.
 I think it's definitely useful, although I think it should be 
 implemented
 as a suite of flags, not just a single one. Sure, a convenience 
 flag can be
 offered, but as an implementation detail, it should be a suite 
 of flags.


I like this and I also think providing compiler switches (ie. 
without naming the subset) as being acceptable.

However, what if I would need those switches for just one 
particular module and the functions therein? How to compile only 
those modules with the switches?

Only through manual compile/linking?



 Feb 11 2014



  parent reply Manu <turkeyman gmail.com>  writes:


On 12 February 2014 16:11, eles <eles eles.com> wrote:


 On Wednesday, 12 February 2014 at 03:28:57 UTC, Manu wrote:


 On 12 February 2014 12:11, Manu <turkeyman gmail.com> wrote:

  On 12 February 2014 05:43, Walter Bright <newshound2 digitalmars.com>

 wrote:





 I've changed my mind. Depending on a functional link-stripper sucks.
 I think it's definitely useful, although I think it should be implemented
 as a suite of flags, not just a single one. Sure, a convenience flag can
 be
 offered, but as an implementation detail, it should be a suite of flags.


 I like this and I also think providing compiler switches (ie. without
 naming the subset) as being acceptable.

 However, what if I would need those switches for just one particular
 module and the functions therein? How to compile only those modules with
 the switches?

 Only through manual compile/linking?


Yes, exactly as with C++ today. It shouldn't be an unfamiliar problem to
most.



 Feb 12 2014



  parent reply "John Colvin" <john.loughran.colvin gmail.com>  writes:


On Wednesday, 12 February 2014 at 14:15:55 UTC, Manu wrote:

 On 12 February 2014 16:11, eles <eles eles.com> wrote:


 On Wednesday, 12 February 2014 at 03:28:57 UTC, Manu wrote:


 On 12 February 2014 12:11, Manu <turkeyman gmail.com> wrote:

  On 12 February 2014 05:43, Walter Bright 
 <newshound2 digitalmars.com>

 wrote:





 I've changed my mind. Depending on a functional link-stripper 
 sucks.
 I think it's definitely useful, although I think it should be 
 implemented
 as a suite of flags, not just a single one. Sure, a 
 convenience flag can
 be
 offered, but as an implementation detail, it should be a 
 suite of flags.


 I like this and I also think providing compiler switches (ie. 
 without
 naming the subset) as being acceptable.

 However, what if I would need those switches for just one 
 particular
 module and the functions therein? How to compile only those 
 modules with
 the switches?

 Only through manual compile/linking?


 Yes, exactly as with C++ today. It shouldn't be an unfamiliar 
 problem to
 most.


How does that work with templates across modules?



 Feb 12 2014



  parent reply Manu <turkeyman gmail.com>  writes:


On 13 February 2014 00:25, John Colvin <john.loughran.colvin gmail.com>wrote:


 On Wednesday, 12 February 2014 at 14:15:55 UTC, Manu wrote:


 On 12 February 2014 16:11, eles <eles eles.com> wrote:

  On Wednesday, 12 February 2014 at 03:28:57 UTC, Manu wrote:

  On 12 February 2014 12:11, Manu <turkeyman gmail.com> wrote:

  On 12 February 2014 05:43, Walter Bright <newshound2 digitalmars.com>


 wrote:




  I've changed my mind. Depending on a functional link-stripper sucks.

 I think it's definitely useful, although I think it should be
 implemented
 as a suite of flags, not just a single one. Sure, a convenience flag can
 be
 offered, but as an implementation detail, it should be a suite of flags.


 I like this and I also think providing compiler switches (ie. without
 naming the subset) as being acceptable.

 However, what if I would need those switches for just one particular
 module and the functions therein? How to compile only those modules with
 the switches?

 Only through manual compile/linking?


 Yes, exactly as with C++ today. It shouldn't be an unfamiliar problem to
 most.


 How does that work with templates across modules?


I'm not sure how that would affect anything? Only a couple of runtime
things would be unavailable, and ideally individually unavailable on
different flags.



 Feb 12 2014



  parent reply "John Colvin" <john.loughran.colvin gmail.com>  writes:


On Wednesday, 12 February 2014 at 14:36:21 UTC, Manu wrote:

 On 13 February 2014 00:25, John Colvin 
 <john.loughran.colvin gmail.com>wrote:


 On Wednesday, 12 February 2014 at 14:15:55 UTC, Manu wrote:


 On 12 February 2014 16:11, eles <eles eles.com> wrote:

  On Wednesday, 12 February 2014 at 03:28:57 UTC, Manu wrote:

  On 12 February 2014 12:11, Manu <turkeyman gmail.com> wrote:

  On 12 February 2014 05:43, Walter Bright 
 <newshound2 digitalmars.com>


 wrote:




  I've changed my mind. Depending on a functional 
 link-stripper sucks.

 I think it's definitely useful, although I think it should 
 be
 implemented
 as a suite of flags, not just a single one. Sure, a 
 convenience flag can
 be
 offered, but as an implementation detail, it should be a 
 suite of flags.


 I like this and I also think providing compiler switches 
 (ie. without
 naming the subset) as being acceptable.

 However, what if I would need those switches for just one 
 particular
 module and the functions therein? How to compile only those 
 modules with
 the switches?

 Only through manual compile/linking?


 Yes, exactly as with C++ today. It shouldn't be an unfamiliar 
 problem to
 most.


 How does that work with templates across modules?


 I'm not sure how that would affect anything? Only a couple of 
 runtime
 things would be unavailable, and ideally individually 
 unavailable on
 different flags.


What I mean is: template in module A that needs one of these 
flags is instantiated from module B that needs to *not* have that 
flag.



 Feb 12 2014



  parent reply Johannes Pfau <nospam example.com>  writes:


Am Wed, 12 Feb 2014 14:37:53 +0000
schrieb "John Colvin" <john.loughran.colvin gmail.com>:


 
 What I mean is: template in module A that needs one of these 
 flags is instantiated from module B that needs to *not* have that 
 flag.


The template is emitted to the object file of module B, so only the
flags used with B matter and as long as 'these flags' are a strict
subset, it's always possible to use the same code in standard D.

(It is kinda important that we produce the same code in both cases
though - otherwise weird things can happen if the linker merges
template instances)



 Feb 12 2014



  parent reply "Sean Kelly" <sean invisibleduck.org>  writes:


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.



 Feb 12 2014



 next sibling parent  "Brian Rogoff" <brogoff gmail.com>  writes:


On Wednesday, 12 February 2014 at 15:40:54 UTC, 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.


Good compiler flag name choice.


 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.


By 'nod' you mean Bugzilla entry, right? The flag would have to 
be documented. While "better C" is descriptive, it's not very 
helpful.

I like the idea a lot. If it's truly low hanging fruit, then yeah 
it should be done, but I get the concerns that others have about 
D and unfinished business. Tough decision!



 Feb 12 2014



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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.

Andrei



 Feb 12 2014



 next sibling parent  "Chris" <wendlec tcd.ie>  writes:


On Wednesday, 12 February 2014 at 16:30:29 UTC, Andrei 
Alexandrescu 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.

 Andrei


But keep -minimal in mind. A good idea, both the concept and the 
flag name.



 Feb 12 2014



prev sibling next sibling parent  "Dicebot" <public dicebot.lv>  writes:


On Wednesday, 12 February 2014 at 16:30:29 UTC, Andrei 
Alexandrescu wrote:

 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.

 Andrei


Cruel world :)



 Feb 12 2014



prev sibling next sibling parent  "Gary Willoughby" <dev nomad.so>  writes:


On Wednesday, 12 February 2014 at 16:30:29 UTC, Andrei 
Alexandrescu wrote:

 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.

 Andrei


Thank god! Splintering the community, causing confusion and 
diverting effort between these would of been a nightmare for the 
popularity and up-take of D, especially as real interest is 
starting to be shown from across the board. Plus, there's no real 
reason why after the allocator/arc/gc changes are made D will be 
able to fill this niche itself.

I had nightmares of a new Phobos/Tango war being created for 
small D. :/



 Feb 12 2014



prev sibling next sibling parent  John J <john.joyus gmail.com>  writes:


On 02/12/2014 11:30 AM, Andrei Alexandrescu wrote:

 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.


Too busy to innovate! ;)



 Feb 12 2014



prev sibling  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


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



 Feb 13 2014



  parent  1100110 <0b1100110 gmail.com>  writes:


On 2/13/14, 11:21, Steven Schveighoffer wrote:

 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


I'm putting a $50 dollar bounty on it.  Gotta work out the details, but 
there it is.  It's on the announcements forum.

Anyone wanna chip in?  I really want something like this to be implemented.



 Feb 13 2014



prev sibling next sibling parent  "Jesse Phillips" <Jesse.K.Phillips+D gmail.com>  writes:


On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:

 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.


I think it should be something acceptable for mainline, but 
should be the pursuit of those who are going to use it to 
implement it (unless other things finished).

I can not speak to the usefulness of this as I don't see myself 
as a user, but it sounds like something which will be desired by 
many (but I expect their to be other blockades preventing it from 
being a major growth to D).



 Feb 11 2014



prev sibling next sibling parent  "Mike" <none none.com>  writes:


On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:

 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.


Why would a working phobos prevent bringing D to a new platform.  
Did you mean the "D Runtime"?

Mike



 Feb 12 2014



prev sibling next sibling parent  Jordi Sayol <g.sayol yahoo.es>  writes:


El 11/02/14 20:43, Walter Bright ha escrit:

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


DonC

-- 
Jordi Sayol



 Feb 12 2014



prev sibling next sibling parent  "Chris" <wendlec tcd.ie>  writes:


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


-DinC (= D Inc.)
-bareD
-Dwalk (as opposed to D run(time)) ouch!

(Disclaimer: I haven't read all comments, the names might already 
have been suggested)



 What do you think?


I like the idea.



 Feb 12 2014



prev sibling next sibling parent  "Andrea Fontana" <nospam example.com>  writes:


On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:

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


Too bad C+ is already taken.


 What do you think?


Good idea, but I'm afraid that a new phobos-like library will 
born. We have a better C with a old-style stdc library? I don't 
think I'm going to use "C+" with printf(), fopen(), fclose() and 
their old code style and syntax and I'll finish writing some 
wrappers over them using the d-power.

Probably that's good for platform like arduino where c std 
library is not used...

Or maybe we should provide some basic wrappers over stdc library 
using d-style.



 Feb 12 2014



prev sibling next sibling parent  John J <john.joyus gmail.com>  writes:


On 02/11/2014 02:43 PM, 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?)


A new switch?
-OnlyC

A new language?
CD



 Feb 12 2014



prev sibling next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2014-02-11 20:43, 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?)


-no-runtime


 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 don't mind it.

Funny thing tough: complaining that warnings are not good because they 
would create a separate language. Then I see this proposal.

-- 
/Jacob Carlborg



 Feb 12 2014



  parent  "Tove" <tove fransson.se>  writes:


On Wednesday, 12 February 2014 at 20:10:42 UTC, Jacob Carlborg 
wrote:

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


 -no-runtime


good choice and even if Walter is blocked on higher prio issues, 
we can still make it happen as a community.



 Feb 12 2014



prev sibling next sibling parent reply "inout" <inout gmail.com>  writes:


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.



 Feb 13 2014



 next sibling parent  "Rel" <relmail rambler.ru>  writes:


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!



 Feb 13 2014



prev sibling  parent reply Paulo Pinto <pjmlp progtools.org>  writes:


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



 Feb 13 2014



 next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


On Thursday, 13 February 2014 at 19:47:33 UTC, Paulo Pinto wrote:

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


distributing binary libraries for barebone? that sounds unusual.



 Feb 13 2014



  parent reply Paulo Pinto <pjmlp progtools.org>  writes:


Am 13.02.2014 20:51, schrieb Dicebot:

 On Thursday, 13 February 2014 at 19:47:33 UTC, Paulo Pinto wrote:

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


 distributing binary libraries for barebone? that sounds unusual.


Why so?



 Feb 13 2014



  parent reply "Dicebot" <public dicebot.lv>  writes:


On Thursday, 13 February 2014 at 20:12:36 UTC, Paulo Pinto wrote:

 distributing binary libraries for barebone? that sounds 
 unusual.


 Why so?


untypical hardware + desire to get most of it makes hard to 
provide binary distributions that can be simply linked to. Only 
platform SDK's come to my mind but those don't need to support 
all possible options - instead they define only "right" ones to 
use. Well, at least that was small observation of C barebone 
world I have managed to tackle.



 Feb 13 2014



  parent  "Mike" <none none.com>  writes:


On Thursday, 13 February 2014 at 20:34:50 UTC, Dicebot wrote:

 On Thursday, 13 February 2014 at 20:12:36 UTC, Paulo Pinto 
 wrote:

 distributing binary libraries for barebone? that sounds 
 unusual.


 Why so?


 untypical hardware + desire to get most of it makes hard to 
 provide binary distributions that can be simply linked to. Only 
 platform SDK's come to my mind but those don't need to support 
 all possible options - instead they define only "right" ones to 
 use. Well, at least that was small observation of C barebone 
 world I have managed to tackle.


SDKs and BSPs are the norm in my industry, but some libraries are 
out there (http://www.segger.com/pricing.html)... and they are 
expensive.  But I think they are usually source releases.



 Feb 13 2014



prev sibling  parent  "inout" <inout gmail.com>  writes:


On Thursday, 13 February 2014 at 19:47:33 UTC, Paulo Pinto wrote:

 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


These could be linker flags. If you distribute your library as a
.lib, all of those could be present (and only stripped at
link-time).



 Feb 13 2014



prev sibling next sibling parent reply "Kagamin" <spam here.lot>  writes:


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.



 Feb 13 2014



  parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


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.



 Feb 13 2014



  parent reply "Kagamin" <spam here.lot>  writes:


On Thursday, 13 February 2014 at 19:09:21 UTC, Adam D. Ruppe 
wrote:

 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.


_d_array_bounds must report the location of error, so it should 
take ModuleInfo and line number to report, where it happened.



 Feb 14 2014



  parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Friday, 14 February 2014 at 17:21:09 UTC, Kagamin wrote:

 _d_array_bounds must report the location of error, so it should 
 take ModuleInfo and line number to report, where it happened.


It could simply take a string. That's all druntime does anyway: 
fetch m.name from moduleinfo then proceed normally.



 Feb 14 2014



  parent  "Kagamin" <spam here.lot>  writes:


On Friday, 14 February 2014 at 17:37:20 UTC, Adam D. Ruppe wrote:

 On Friday, 14 February 2014 at 17:21:09 UTC, Kagamin wrote:

 _d_array_bounds must report the location of error, so it 
 should take ModuleInfo and line number to report, where it 
 happened.


 It could simply take a string. That's all druntime does anyway: 
 fetch m.name from moduleinfo then proceed normally.


With single pointer the calling code is more minimal. Also it's 
more conceptual: D is module-oriented and with module name you 
don't need file name. What's problem with moduleinfo? It's only 8 
bytes + module name.



 Feb 15 2014



prev sibling next sibling parent  "Dejan Lekic" <dejan.lekic gmail.com>  writes:


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



 Feb 13 2014



prev sibling next sibling parent  "exord" <exord live.cn>  writes:


Cool, this is what I have been seeking for several years.

I have to face C everyday totally because my work needs it.
But I hate it!



convinient for me and I really don't need some advance features 
such as GC, runtime support and library support.I don't need a 
full framwork, I just needs a language.

When I first had a glance of D, I think it is what I need. I 
don't need to write down a separate include file and I have 
well-orged namespace, and most fantasict thing is it compiles to 
native binary!

But as I looked into more, I think D are becoming more and more 
complex. Even to learn it will take someone lots of time. If we 
can prvide several variants or subsets will be helpful, such for 
system developer/web developer, they will only need to learn the 
things releated their variant.



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?





 Feb 16 2014



prev sibling next sibling parent  Marco Leise <Marco.Leise gmx.de>  writes:


Am Tue, 11 Feb 2014 11:43:02 -0800
schrieb Walter Bright <newshound2 digitalmars.com>:


 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?


That sounds like it has use cases and doesn't create anything
new, just restrict the feature set like  safe.
I expect that it is much easier to port D to all kinds of
platforms where it is a lot of work or even impossible to
implement all of D's features. Since objects and the GC are
out, it means that D threads are also out.
What about TLS? It has proven difficult on previous MacOS X
versions already and might cause trouble on other platforms.

This morning I talked with my father about the use of Python
in controlling motors and sensors for the saws he is
constructing at work. I don't know how Python works on such an
embedded platform, but I could see "better C" there as well.
Especially since Python did cause trouble when real time
feedback was required.

-- 
Marco



 Feb 17 2014



prev sibling  parent reply "Rel" <relmail rambler.ru>  writes:


On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:

 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?


So may I ask, what is official decision on the subject? Quite a 
lot of people were begging for it for a long time. Obviously I'd 
like to have this feature in D because it would finally allow 
game, embedded, system (and operating system) developers to use 
good, modern and beautiful language for their needs. As for me 
I've been waiting for this for a long time. Hacking on compiler 
and phobos in order to make it generate stdlib-indepentent code 
may be interesting from time to time, but keeping such kind of 
project up-to-date with each new version of the compiler can be 
quite hard. Supporting a subset of D language features suitable 
for system/embedded programming and porting seems to be the best 
decision in this case.



 Feb 18 2014



 next sibling parent  "Dicebot" <public dicebot.lv>  writes:


On Tuesday, 18 February 2014 at 12:20:52 UTC, Rel wrote:

 So may I ask, what is official decision on the subject? Quite a 
 lot of people were begging for it for a long time. Obviously 
 I'd like to have this feature in D because it would finally 
 allow game, embedded, system (and operating system) developers 
 to use good, modern and beautiful language for their needs.


Don't overexpect - it will make experiments easier in that 
direction but is not necessarily an enabler proposal. Its 
importance is rated too high in that regard.

That said, official resolution seems to be "have good chance of 
being accepted if anything else implements it, but Walter won't 
spend time personally"



 Feb 18 2014



prev sibling  parent reply "Tim Krimm" <invalidEmail 123.com>  writes:


On Tuesday, 18 February 2014 at 12:20:52 UTC, Rel wrote:

 On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright 
 wrote:

 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?


 So may I ask, what is official decision on the subject? Quite a 
 lot of people were begging for it for a long time. Obviously 
 I'd like to have this feature in D because it would finally 
 allow game, embedded, system (and operating system) developers 
 to use good, modern and beautiful language for their needs. As 
 for me I've been waiting for this for a long time. Hacking on 
 compiler and phobos in order to make it generate 
 stdlib-indepentent code may be interesting from time to time, 
 but keeping such kind of project up-to-date with each new 
 version of the compiler can be quite hard. Supporting a subset 
 of D language features suitable for system/embedded programming 
 and porting seems to be the best decision in this case.


I have also been waiting for something like this for a long time.



 Feb 19 2014



  parent  "Rel" <relmail rambler.ru>  writes:


On Wednesday, 19 February 2014 at 15:46:38 UTC, Tim Krimm wrote:

 On Tuesday, 18 February 2014 at 12:20:52 UTC, Rel wrote:

 On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright 
 wrote:

 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?


 So may I ask, what is official decision on the subject? Quite 
 a lot of people were begging for it for a long time. Obviously 
 I'd like to have this feature in D because it would finally 
 allow game, embedded, system (and operating system) developers 
 to use good, modern and beautiful language for their needs. As 
 for me I've been waiting for this for a long time. Hacking on 
 compiler and phobos in order to make it generate 
 stdlib-indepentent code may be interesting from time to time, 
 but keeping such kind of project up-to-date with each new 
 version of the compiler can be quite hard. Supporting a subset 
 of D language features suitable for system/embedded 
 programming and porting seems to be the best decision in this 
 case.


 I have also been waiting for something like this for a long 
 time.


Well in my opinion the language should be started with a fixed 
number of features, that are not dependent on runtime, then 
improve the language by adding features supported by runtime 
library. Too bad that D doesn't officially support a subset 
without runtime depemdencies, so we have to either use C/C++ or 
keep on trying to hack on of D compilers. On the other hand Rust 
can be used without runtime libraries.



 Mar 20 2014