On 12 February 2014 05:43, Walter Bright <newshou...@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.
