Don wrote:
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.
Well actually it's always been at least in the early discussions, I was
actually surprised that dmd doesn't yet accept it lexically.
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.
Agreed, module(safe) would be unnecessary if everything was safe unless
overrode with "system". This would be a hard sell to Walter, however. It
would be a hard sell to you, too - don't forget that safe + no bounds
checking = having the cake and eating it.
module(safe) is not a comment. We need three types of modules because of
the interaction between what the module declares and what the command
line wants.
Let's assume the default, no-flag build allows unsafe code, like right
now. Then, module(safe) means that the module volunteers itself for
tighter checking, and module(system) is same as module unadorned.
But then if the user compiles with -safe, module(safe) is the same as
module unadorned, and module(system) allows for unchecked operations in
that particular module. I was uncomfortable with this, but Walter
convinced me that D's charter is not to allow sandbox compilation and
execution of malicious code. If you have the sources, you may as well
take a look at their module declarations if you have some worry.
Regardless on the result of the debate regarding the default compilation
mode, if the change of that default mode is allowed in the command line,
then we need both module(safe) and module(system).
On a loosely-related vein, I am starting to think it would be a good
idea to refine the module declaration some more. It's a great way to
have fine-grained compilation options without heavy command-line options.
module(safe, contracts, debug) mymodule;
This means the module forces safety, contract checks, and debug mode
within itself, regardless on the command line.
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.
Indeed. I hope so :o).
\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.
Well I wouldn't want to go any dirtier than "system", so my "system"
would be your "sysinternal". I'd like to milden "system" a bit like in
e.g. "trusted", which would be your "system".
Andrei
