<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 12 February 2014 12:11, Manu <span dir="ltr"><<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">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><div>D-- ;)</div><div class=""><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></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>
</blockquote></div><br></div><div class="gmail_extra">I've changed my mind. Depending on a functional link-stripper sucks.</div><div class="gmail_extra">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.</div>
</div>