Bill Baxter wrote:
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
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
