safety model in D

Don nospam at nospam.com
Wed Nov 4 04:23:58 PST 2009


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.



More information about the Digitalmars-d mailing list