safety model in D

[Andrei Alexandrescu]

Tim Matthews wrote:
> Andrei Alexandrescu wrote:
>> SafeD is, unfortunately, not finished at the moment. I want to leave 
>> in place a stub that won't lock our options. Here's what we currently 
>> have:
>>
>> module(system) calvin;
>>
>> This means calvin can do unsafe things.
>>
>> module(safe) susie;
>>
>> This means susie commits to extra checks and therefore only a subset 
>> of D.
>>
>> module hobbes;
>>
>> This means hobbes abides to whatever the default safety setting is.
>>
>> The default safety setting is up to the compiler. In dmd by default it 
>> is "system", and can be overridden with "-safe".
>>
>> Sketch of the safe rules:
>>
>> \begin{itemize*}
>> \item No @cast@ from a pointer type to an integral type and vice versa
>> \item No @cast@ between unrelated pointer types
>> \item Bounds checks on all array accesses
>> \item  No  unions  that  include  a reference  type  (array,  @class@,
>>   pointer, or @struct@ including such a type)
>> \item No pointer arithmetic
>> \item No escape of a pointer  or reference to a local variable outside
>>   its scope
>> \item Cross-module function calls must only go to other @safe@ modules
>> \end{itemize*}
>>
>> So these are my thoughts so far. There is one problem though related 
>> to the last \item - there's no way for a module to specify "trusted", 
>> meaning: "Yeah, I do unsafe stuff inside, but safe modules can call me 
>> no problem". Many modules in std fit that mold.
>>
>> How can we address that? Again, I'm looking for a simple, robust, 
>> extensible design that doesn't lock our options.
>>
>>
>> Thanks,
>>
>> Andrei
> 
> Not sure if this is the right topic to say this but maybe D needs monads 
> to allow more functions to be marked as pure. Then functional could be 
> added to the list of paradigms D supports and will also be safer.

Would be great if you found the time to write and discuss a DIP.

Andrei