On Friday, 27 April 2018 at 00:21:51 UTC, sarn wrote:
I think you've got the technical answer already (just don't link in phobos2) but I'll add my 2c that Phobosless programming isn't just possible but realistically doable. It's a shame to go without Phobos because it's got so much higher-level functionality, but if you're okay with writing things from the ground up in C-like code, it works. Most third-party D libraries depend on Phobos, though, so it's mostly DIY and using bindings to other languages.

Right, that’s the plan for the program itself. Even without D we would be talking to services as directly as possible, and third party libraries would come in as C code and be tweaked to work in-house. Performance is paramount with this, which is why I was so pleased to find out about the ‘-betterC’ switch in development, even though we may have gotten by with a minimal D runtime. The ecosystem at work here is really something else :)

On Friday, 27 April 2018 at 00:21:51 UTC, sarn wrote:
Have a look at the standard library here:
https://dlang.org/phobos/index.html

Basically, all the std.* is Phobos, and most of the core.* stuff needs linking with the D runtime library. However, there's a bunch of bindings to standard C stuff in core.stdc.* that only need the C runtime and standard library, and these come in really handy when you're not using Phobos. (There are more platform-specific C bindings in core.sys.* that aren't listed on that page.) Also, there are some other things in core.bitop and core.atomic (probably more) that don't need linking to druntime.

Right. So there isn’t anything in core.* that would be in libphobos, only D runtime? And std.* depends on both, that is correct? Just want to be sure there aren’t edge cases or exceptions, it would be a handy rule of thumb.

Reply via email to