That page specifies a rationale of: code loaded from C will not load the D runtime. Is it also possible to provide a C-callable shared D library that initializes the runtime dynamically? Would you then get some missing features like global constructors?
Googling around seems to suggest there is rt_init or Runtime.initialize for that?
I've never used D, I'm just curious about the problem described.
Ps. Goes without saying that i, like others, appreciate your comments here.
If the D code is aware that it needs to initialize the runtime then yes, either that you or you initialize it yourself before using it.
rt_init will fire up the D runtime.
As for constructors the runtime should handle those when the module is initialised, so not necessarily on program start up or the DSO being loaded.
If, however, you want to register a C runtime constructor you can do do so with pragma(crt_constructor).
I actually recently-ish fixed a bug to make the aforementioned type of constructor work on MacOS because Apple decided to deprecate them with no reason.
Googling around seems to suggest there is rt_init or Runtime.initialize for that?
I've never used D, I'm just curious about the problem described.
Ps. Goes without saying that i, like others, appreciate your comments here.