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