safety model in D

[Michel Fortin]

On 2009-11-03 17:33:39 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> 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.

What you want is to define the safety of the implementation separately 
from the safety of the interface. A safe module interface means that 
you can use the module in safe code, while a system interface forbid 
using the module in safe code. You could do this with two values in the 
parenthesis:

	module (<interface-safety>, <implementation-safety>) <name>;

	module (system, system) name; // interface: unsafe   impl.: unsafe
	module (safe, safe) name;     // interface: safe     impl.: safe
	module (safe, system) name;   // interface: safe     impl.: unsafe
	module (system, safe) name;   // interface: unsafe   impl.: safe

(The last one is silly, I know.)

Then define a shortcut so you don't have to repeat yourself when the 
safety of the two is the same:

	module (<interface-and-implementation-safety>) <name>;

	module (system) name;         // interface: unsafe   impl.: unsafe
	module (safe) name;           // interface: safe     impl.: safe

Of note, this also leaves the door open to a more fine-grained security 
policy in the future. We could add an 'extra-safe' or 'half-safe' mode 
if we wanted.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/