[Dlang-internal] druntime: proposed changes in code organization

[Denis Feklushkin]

On Friday, 1 December 2023 at 12:53:55 UTC, IGotD- wrote:

> Thank you, now I have a better understanding what a tag is. 
> Correct me if I'm wrong so these tags are like "feature 
> defines" similarly to a boatload of C defines that you must 
> define for certain C-libraries.

No, if I correctly understand this "C features defines" concept

> Will these tags eventually become version identifiers inside 
> the code?

No

> Also one question if the tags are visible inside the D code or 
> just outside the code in the build system?

Tags are visible only for druntime build system

>>
>>> The PR doesn't mention anything about the generic part of the 
>>> implementation. Where should the generic part be?
>>
>> I don’t understand what is meant by "generic part" here
>>
>
> We have OS/API specific code in druntime but also generic code 
> that can be shared by all OSes. What I was looking for is an 
> explanation where this generic code should located. Will it be 
> like it is right now and you break out the OS specific code and 
> put it in druntime/config/?

Yes, this is correct

Good example is event.d - proposed PR splits it into 3 files: 
Posix and Windows implementations and also shared between OSes 
module druntime/src/core/internal/event_tests.d, containing 
mandatory unittests which are common for all Event implementations

> For example we can make the code in 
> druntime/src/core/thread/osthread.d (which is absolutely 
> horrible) and start to define what is OS independent, leave it 
> inside osthread.d and then put OS dependent stuff in the new 
> files?

Specifically for osthread.d:

At first step I propose some small refactoring for osthread.d: it 
is need to move code shared for all OSes into 
"core.thread.threadbase" module. As I remember, community wanted 
to do this for a long time but there was no reason to begin this 
process.

Then we can move osthread.d into confing/ and also split it into 
Windows and non-Windows versions

All this can be done gradually. We don't even forced to split 
osthread.d at first stages if we afraid to broke something.