jpf wrote:
Andrei Alexandrescu wrote:
How can we address that? Again, I'm looking for a simple, robust,
extensible design that doesn't lock our options.
Thanks,
Andrei
You may want to have a look at the CoreCLR security model (that's used
by silverlight / moonlight). It's quite similar to what you've proposed.
http://www.mono-project.com/Moonlight2CoreCLR#Security_levels
I don't have much time right now, but here's what a cursory look reveals:
====================
Security levels
The CoreCLR security model divide all code into three distinct levels:
transparent, safe-critical and critical. This model is much simpler to
understand (and implement) than CAS (e.g. no stack-walk). Only a few
rules can describe much of it.
====================
The keywords "security" and "stack-walk" give it away that this is a
matter of software security, not language safety. These are quite different.
Btw, is there a reason why safety should be specified at the module
level? As we have attributes now that would be a perfect usecase for
them: example:
@Safety(Safe)
void doSomething()...
or:
@Safety.Critical
void doSomething()...
where that attribute could be applied to functions, classes, modules, ...
Another related question: Will there be a way to provide different
implementations for different safety levels?
version(Safety.Critical)
{
//Some unsafe yet highly optimized asm stuff here
}
else
{
//Same thing in safe
}
I think it muddies things too much to allow people to make safety
decisions at any point (e.g., I'm not a fan of C#'s unsafe).
Andrei
