D as A Better C?

[Manu]

On 12 February 2014 05:43, Walter Bright <newshound2 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140212/7bc8717b/attachment.html>