The Future of D Runtime

[Adam Wilson]

On Tuesday, 11 June 2024 at 00:01:01 UTC, Walter Bright wrote:
> On 6/8/2024 8:10 PM, Adam Wilson wrote:
>> For example, let's say you want to do some asynchronous I/O. 
>> Forget the CRT, it just doesn't do that. So off you go to the 
>> system API's anyways. Or kludges like Photon. (Don't get me 
>> wrong, Photon is a very cool piece of work, but the nature of 
>> it's implementation means that it suffers from the inherent 
>> limitations and drawbacks of fibers, and does so in a highly 
>> obfuscated way.)
>
> I don't understand how the CRT impedes any of that, or why any 
> of it needs to be worked around. And D is intended to work with 
> hybrid C/D code, so the CRT support needs to be there.

Strictly speaking it doesn't "impede" it, but it does introduce 
multiple code-paths into the code. Let's say you want to do some 
Async File I/O. You simply can't in CRT because it's just not a 
thing that CRT does. Since you *have* to write code using the 
system interfaces to do this, you are going to write the System 
API path, so why not just use the System API path and cut out the 
middle-man?

I am not suggesting that we remove support for CRT from the 
language. Only that we build DRT such that it minimizes or 
completely removes it's use. We've also discussed a design where 
we continue to provide a CRT enabled version of DRT to make 
porting to new platforms easier, but would use the System API 
code paths by default on systems where those have been 
implemented. More work, because Phobos would have to be aware 
that you're using it and appropriately remove the code that CRT 
cannot support, but potentially worth it.

> The CRT also does some startup initialization things that need 
> doing, like collecting the command line arguments to present to 
> the program.

On Windows you use `CommandLineToArgvW`, on Linux/BSD's you might 
actually use the CRT, I don't know what the equivalent is on 
MacOS.