safety model in D

Tim Matthews tim.matthews7 at gmail.com
Wed Nov 4 20:27:47 PST 2009


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.



More information about the Digitalmars-d mailing list