On Tue, Nov 3, 2009 at 2:33 PM, Andrei Alexandrescu <[email protected]> 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
