On 19/06/2024 5:29 AM, Atila Neves wrote:
>     Ok, then were does the Event Loop go?
> 
> What event loop? Unless we add a language feature for this I don't see why it would belong in drt.

Adam is using different meanings to terminology we use.

A runtime in literature can also refer to the standard library, I did warn him about this particular confusion as it does not match the D communities understanding of the word.

Basically what he is suggesting is that there is a series of libraries starting from what is needed to make ``new`` clean up (it doesn't have to), eventloop and other core dependencies that things in our standard library require to have a binary linked against for.

Either way it needs a binary to be inside of. Regardless of if we call it part of phobos or druntime. It can't live as an import only library.

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.