The Future of D Runtime

[Dukc]

Atila Neves kirjoitti 18.6.2024 klo 20.29:
> 
> Not in drt itself, no. But why would we have to?
> 
> 

He already explained it in the original post:

> The most often given reason for keeping DRT as-is is that “we only need to port DRT to a new platform, Phobos is platform independent.” I submit that this is factually incorrect. There are currently 31 files in Phobos with `version (WinXXXX)` statements in them. 14 with `version (linux)`. And IIRC everybody who has tried a port D to a new platform recently has just not bothered to port Phobos at all. To be sure, some of these version statements are benign, but take a look at `std.stdio`, I wish whoever wants to port that much luck in their endeavors. It has 32 instances `version (WinXXXX)` alone. And that is our basic I/O module.
> 
> [snip]
> 
> An example of why this matters is found in `std.stdio`. We currently use the C Runtime to do basic I/O operations. While that works and is expedient, it limits us. For example, doing colored terminal output is so difficult nobody does it, or, we are limited to the C file interface, etc. To gain access to more advanced capabilities, we need to use the system API’s, but these are diverse, and putting them in Phobos would significantly expand the code required and make maintenance a nightmare. What is interesting about this is that, in fact, D has two runtimes. The C Runtime, which we use as a universal system interface, and the DRT which is a bunch of compiler support tools that the CRT doesn’t have. 

To do IO in a modern way (as opposed to the standard C way) an event 
loop is probably needed.

If you read the rest of his post, you can see it's arguable if he is 
actually suggesting doing that in the runtime. He is suggesting to 
"shard" the runtime so that there would be a core "shard" that does what 
the runtime does now, and other shards that do stuff like event loop, 
io, file access primitives and so on, so that Phobos could be built on 
those without platform-specific code in it. Those other shards would all 
be optional, so that if you don't use them (or parts of Phobos or other 
libraries that depend on them), you could still write D on platform the 
optional shards aren't ported to.

When Adam writes about the runtime, he means all the proposed shards. I 
personally feel runtime should only mean the core shard, but this is 
only a difference in terminology. Either way, the proposal is to 
implement the event loop in one of the optional shards, not the core shard.