Andrei Alexandrescu 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.
Where did susie come from? Only module(system) has been discussed
before. Why the need for THREE types of modules? Distinguishing hobbes
and susie seems pointless -- either hobbes is safe, or else it will not
compile with the -safe switch (and it won't compile at all, on a
compiler which makes safe the default!!). It seems that module(safe) is
simply a comment, "yes, I've tested it with the -safe switch, and it
does compile". Doesn't add any value that I can see.
As I understood it, the primary purpose of 'SafeD' was to confine the
usage of dangerous constructs to a small number of modules. IMHO, the
overwhelming majority of modules should not require any marking.
\item Cross-module function calls must only go to other @safe@ modules
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.
How can we address that? Again, I'm looking for a simple, robust,
extensible design that doesn't lock our options.
This actually seems pretty similar to public/private.
I see three types of modules:
module : the default, should compile in -safe mode.
module(system) : Modules which need to do nasty stuff inside, but for
which all the public functions are safe.
module(sysinternal/restricted/...): Modules which exist only to support
system modules. This will include most APIs to C libraries.
Modules in the outer ring need to be prevented from calling ones in the
inner ring.
