Final by default?

[Walter Bright]

On 3/17/2014 12:18 PM, Sean Kelly wrote:
> So I'd import "core.sys.ucontext.package" if I didn't want a
> system-specific module (which should be always)?

No,

     import core.sys.ucontext;

Yes, ucontext is a directory. The package.d is a magic file name. This is the 
new package design that was incorporated last year, designed specifically to 
allow single imports to replaced by packages without affecting user code.


> Why this approach and not publishing modules from somewhere into core.sys
> on install?

The short answer is I happen to have a fondness for installs that are simple 
directory copies that do not modify/add/remove files. I think we are safely 
beyond the days that even a few hundred extra files installed on the disk are a 
negative.

Even if the non-used platform packages are simply deleted on install, this will 
not affect compilation. I think that's still better than modifying files. I've 
never trusted installers that edited files.

Besides that, there are other strong reasons for this approach:

1. New platforms can be added without affecting user code.

2. New platforms can be added without touching files for other platforms.

3. User follows simple no-brainer rule when looking at OS documentation:

     #include <ucontext.h>

   rewrites to:

     import core.sys.ucontext;

4. Bugs in particular platform support files can be fixed without concern with 
breaking other platforms.

5. Changes in platform support will not touch files for other platforms, greatly 
simplifying the QA review process.

6. D installed on Platform X can be mounted as a remote drive and used to 
compile for Platform Y.