The windows bit was more an issue of that we needed the code somewhere and it was windows-specific, so sys.windows seemed a passable choice. The alternative would be core.internal, though I'm trying to avoid the need for that approach. If you have suggestions for how to handle this, please let me know :-)
Sent from my iPhone On Jun 12, 2011, at 8:37 AM, David Nadlinger <s...@klickverbot.at> wrote: > On 6/12/11 5:06 PM, Andrei Alexandrescu wrote: >> On 6/12/11 1:38 AM, David Nadlinger wrote: >>> core.stdc is the place for C standard library modules, core.sys.* are >>> where the C operating system header translations reside – this is our >>> current policy, right? If so (I can't actually remember any formal >>> decision or discussion), is there a reason we still have so much code in >>> std.c? >>> >>> David >> >> The reason is a smart GSoC student didn't yet come and deprecate them :o). > > Smart? Can't possibly be me… ;) > > On a closer look, I discovered that contrary to core.sys.posix and > core.sys.osx, which only have C header translations, core.sys.windows.* also > contains support code like backtrace.d, thradaux.d, etc. > > Is the »official« package structure actually documented anywhere? > > David