core.cpuid

[Don]

On 04.11.2011 18:27, Jonathan M Davis wrote:
> On Friday, November 04, 2011 08:11 Dejan Lekic wrote:
>> Manu wrote:
>>> Seems like a horrible assumption to make when inventing a systems
>>> programming language that intends to go head to head with C/C++ :)
>>
>> FYI, C/C++ also have cpuid, and it is also pretty low-level like in D (ie.
>> developers rarely use cpuid.h directly). You should not (in practice) use
>> "core" modules anyway.
>
> And why not? Thread is in core. So are other modules that it's perfectly
> normal and acceptable to use. There's nothing wrong with using core modules.
> Many of them are _intended_ to be used. Stuff generally ends up in core
> because the D runtime needs it, not because it's something that the common
> programmer shouldn't be using.

That's largely true, but I would agree with Manu that you shouldn't be 
using core very often. By its nature of being close to the runtime, it's 
typically low-level stuff, and so it's only your low-level code which 
should be using it.

Probably there is some stuff in there which should be moved out of core, 
or possibly with a safer wrapper in std. I'm particularly thinking of 
core.bitop, which currently has a mixture of safe and subtly dangerous 
functions, and only a small part of it is actually required by the runtime.