Some advice about druntime.

[Sean Kelly]

Yonggang Luo wrote:
> This is care about druntime.
> The trunk version is 40 
> First, in file root/trunk/import/core/bitmanip.di, 
> The 8th line of this file is 
> "module bitmanip;" I don't know if it's must be change to module "core.bitmanip" 

It should.  Thank you for catching this.

> And I think the files 
> exception.d 
> memory.d 
> runtime.d 
> thread.d 
> also to be place in the floder root/trunk/import/core/ will be better. (Just a advice) 

The current setup is for modules that are compiled into the runtime 
library to live in src, while import holds header modules both for 
building the runtime and for distribution.  The build process for 
druntime publishes .di files for the modules you list above into 
import/core, however, auto-generated header modules aren't terribly 
readable.  What I'd done in Tango was to use a code beautifier on these 
files during the export process, but then the beautifier I was using 
broke and I had to disable it.  So... I have considered both manually 
creating legible headers as well as simply copying the source files 
during the build process, but I'm still undecided about how best to 
handle this.

> And I am curios the three files in the folder root/trunk/import/std 
> Is this possible to migrate these three files to folder root/trunk/import/core/ ? 
> It's should be more meaningful, means these three file is not a general library, It's just used by the compiler, OR 
> The compiler intrinsic functions, so it belong to 'core', (Just a advice, maybe it's impossible); 

The compiler has the locations of intrinsics hardcoded, so the std 
modules currently exist by necessity.  I hope that in a few more 
releases, DMD might change to look for these in core instead, but it's 
something that hasn't been discussed yet.  For the moment my priority is 
simply to get the runtime functional, finalize the locations of stuff, 
naming, build options, etc.  So while I consider the "std" thing to be a 
hack, it's one that's pretty much invisible to users and so isn't a top 
priority.

> It's possible be a good idea is we migrate the file object.di to the folder root/trunk/import/core/  
> so we have the 
> 
> module core.object 
> module core.bitmanip 
> module core.exception 
> module core.memory 
> module core.runtime 
> module core.thread

This is an interesting idea, but I'm not sure it buys us anything. 
Wherever it lives, the object module will be implicitly imported into 
all D modules.  So the location of this module is really only relevant 
from a filesystem standpoint... plus potential namespace collisions, I 
suppose.  Another issue is that currently, the compiler runtime 
implements this module, and this code is distinct and separate from the 
'core' code.  So moving object into core might confuse things from a 
responsibility standpoint somewhat.

> module core.intrinsic for replacement of std.intrinsic  

core.bitmanip fills this need right now.  It's been brought up before 
that 'bitmanip' may not be the best name for this module (I think Don 
may even have submitted a ticket about this), but I haven't come up with 
anything better yet.

> and we have 
> module core.stdc.* 
> module core.sys.windows.* 
> module core.sys.linux.* 
> module core.sys.posix.* 

Yup.

> and for c 
> we have a special module 
> module core.stdc.stdarg; for replacement for std.stdarg and std.c.stdarg. 
> 
> And I don't know why we need two stdarg file? 
> one is std.stdarg, and the other one is std.c.stdarg? 
> It's so strange. but the content of these two file is the same.

They're the same right now, but they may not remain the same in the 
future.  We need two because each provides vararg support for a 
different calling convention.  So you should use std.stdarg (though 
perhaps this should be in core) for D functions and std.c.stdarg for C 
functions.

> So it's should be file is we merge these two file.

See above.  Personally, I'm now inclined to have:

core.vararg
core.stdc.stdarg

The C stuff in druntime isn't currently being built into a library, but 
that may change.


Sean