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

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.

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?

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.

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.

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.

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.

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?

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

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