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
