Minimal druntime?

[IGotD-]

On Saturday, 27 July 2019 at 17:57:07 UTC, Jonathan M Davis wrote:
> On Saturday, July 27, 2019 8:20:52 AM MDT Ethan via 
> Digitalmars-d wrote:
>> On Saturday, 27 July 2019 at 13:11:23 UTC, Jonathan M Davis 
>> wrote:
>> > It sounds to me like what you want is -betterC.
>
> Personally, I'd pretty much only use -betterC to help port a 
> C/C++ library or program to D. I sure wouldn't want to use a 
> stripped down version of D normally. But if you want to avoid 
> stuff like TypeInfo, or you want your library to just look like 
> it's basically C/C++, then that's the direction you're going. 
> To fully use D's features, you need druntime with everything 
> that it does. In theory, druntime could be improved to be more 
> pay-as-you-go than it is, and work is slowly being done in that 
> area, but what druntime does really does provide language 
> functionality, and trying to avoid parts of it basically means 
> avoiding language functionality. It's not like D's features all 
> come for free.
>
> I actually think that -betterC is mostly a waste of time, 
> because I don't see enough benefit in using a stripped down 
> version of D over just using C++ to bother, but it definitely 
> can have benefits when porting code, and some people seem to 
> think that it's the way to go, much as I really don't 
> understand that.
>
> - Jonathan M Davis

I agree, why limit the D language. Always viewed -betterC as an 
intermediate step until the "pay for what you use" implementation 
is in place. For most embedded systems type/module info and so on 
isn't really much of a problem other those really memory limited 
targets. I regard the type/module info a great help actually even 
for bare metal targets.

What is the problem is the dependency to an operating system and 
how to make this more flexible. Hopefully in the future we can 
decouple the runtime language features (like classes) which 
doesn't really need OS support from things in the runtime that 
needs OS support.