safety model in D

[Andrei Alexandrescu]

Bill Baxter wrote:
> On Tue, Nov 3, 2009 at 2:33 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> 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.
> 
> I have to say that I would be seriously annoyed to see repeated
> references to a feature that turns out to be vaporware.  (I'm guessing
> there will be repeated references to SafeD based on the Chapter 4
> sample, and I'm guessing it will be vaporware based on the question
> you're asking above).  I'd say leave SafeD for the 2nd edition, and
> just comment that work is underway in a "Future of D" chapter near the
> end of the book.  And of course add a "Look to <the publishers website
> || digitalmars.com> for the latest!"
> 
> Even if not vaporware, it looks like whatever you write is going to be
> about something completely untested in the wild, and so has a high
> chance of turning out to need re-designing in the face of actual use.
> 
> --bb

Ok, I won't use the term SafeD as if it were a product. But -safe is 
there, some checks are there, and Walter is apparently willing to 
complete them. It's not difficult to go with an initially conservative 
approach - e.g., "no taking the address of a local" as he wrote in a 
recent post - although a more refined approach would still allow to take 
addresses of locals, as long as they don't escape.


Andrei