<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 12 February 2014 05:43, Walter Bright <span dir="ltr"><<a href="mailto:newshound2@digitalmars.com" target="_blank">newshound2@digitalmars.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've toyed with this idea for a while, and wondered what the interest there is in something like this.<br>
<br>
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.<br>

<br>
(First off, I hate the name "better C", any suggestions?)<br></blockquote><div><br></div><div>D-- ;)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

The subset would disallow use of any features that rely on:<br>
<br>
1. moduleinfo<br>
2. exception handling<br>
3. gc<br>
4. Object<br>
<br>
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.<br>
<br>
What do you think?<br>
</blockquote></div><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Personally, I don't want D--, I want D.</div><div class="gmail_extra">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.</div>
<div class="gmail_extra">I guess the flag is still useful to catch errors where a user attempting to avoid those items hits one by mistake.</div></div>