safety model in D

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed Nov 4 11:12:54 PST 2009


Michal Minich wrote:
> 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 :)

Efficiency (e.g. remove array bounds checks).

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

That would be a great turn of events!!!


Andrei



More information about the Digitalmars-d mailing list