safety model in D

[Andrei Alexandrescu]

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