safety model in D

Michal Minich michal.minich at gmail.com
Wed Nov 4 10:58:26 PST 2009


On Wed, 04 Nov 2009 14:03:42 -0300, Leandro Lucarella wrote:

> I think safe should be the default, as it should be the most used flavor
> in user code, right? What about:
> 
> module s;             // interface: safe     impl.: safe 
> module (trusted) t;   // interface: safe     impl.: unsafe
> module (unsafe) u;    // interface: unsafe   impl.: unsafe
> 
> * s can import other safe or trusted modules (no unsafe for s). * t can
> import any kind of module, but he guarantee not to corrupt your
>   memory if you use it (that's why s can import it).
> * u can import any kind of modules and makes no guarantees (C bindings
>   use this).
> 
>> That's a pretty clean design. How would it interact with a -safe
>> command-line flag?
> 
> I'll use safe by default. If you want to use broken stuff (everything
> should be correctly marked as safe (default), trusted or unsafe) and let
> it compile anyway, add a compiler flag -no-safe (or whatever).
> 
> But people should never use it, unless you are using some broken library
> or you are to lazy to mark your modules correctly.
> 
> 
> Is this too crazy?

I have no problem with safe as default, most of my code is safe. I also 
like the module (trusted) - it really pictures it meanings, better than 
"system". 

But I think there is no reason no use -no-safe compiler flag ... for what 
reason one would want to force safer program to compile as less safer :)

As I'm thinking more about it, I don't see any reason to have any 
compiler flag for safety at all.



More information about the Digitalmars-d mailing list