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.
