On Tue, 03 Nov 2009 17:33:39 -0500, Andrei Alexandrescu
<[email protected]> wrote:
SafeD is, unfortunately, not finished at the moment. I want to leave in
place a stub that won't lock our options. Here's what we currently have:
module(system) calvin;
This means calvin can do unsafe things.
module(safe) susie;
This means susie commits to extra checks and therefore only a subset of
D.
module hobbes;
This means hobbes abides to whatever the default safety setting is.
...
\item Cross-module function calls must only go to other @safe@ modules
\end{itemize*}
So these are my thoughts so far. There is one problem though related to
the last \item - there's no way for a module to specify "trusted",
meaning: "Yeah, I do unsafe stuff inside, but safe modules can call me
no problem". Many modules in std fit that mold.
My interpretation of the module decorations was:
module(system) calvin;
This means calvin uses unsafe things, but is considered safe for other
modules (it overrides the setting of the compiler, so can be compiled even
in safe mode).
module(safe) susie;
This means susie commits to extra checks, and will be compiled in safe
mode even if the compiler is in unsafe mode. Susie can only import
module(safe) or module(system) modules, or if the compiler is in safe
mode, any module.
module hobbes;
This means hobbes doesn't care whether he's safe or not. (note the
important difference from your description)
My rationale for interpreting module(system) is: why declare a module as
system unless you *wanted* it to be compilable in safe mode?
I would expect that very few modules are marked as module(system).
And as for the default setting, I think that unsafe is a reasonable
default. You can always create a shortcut/script/symlink to the compiler
that adds the -safe flag if you wanted a safe-by-default version.
-Steve
