safety model in D

[Jason House]

Walter Bright Wrote:

> Andrei Alexandrescu wrote:
> > Sketch of the safe rules:
> > 
> > \begin{itemize*}
> > \item No @cast@ from a pointer type to an integral type and vice versa
> 
> replace integral type with non-pointer type.
> 
> > \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)
> 
> pointers are not a reference type. Replace "reference type" with 
> "pointers or reference types".
> 
> > \item No pointer arithmetic
> 
> > \item No escape of a pointer  or reference to a local variable outside
> >   its scope
> 
> revise: cannot take the address of a local or a reference.
> 
> > \item Cross-module function calls must only go to other @safe@ modules
> > \end{itemize*}
> 
> add:
> . no inline assembler
> . no casting away of const, immutable, or shared

How does casting away const, immutable, or shared cause memory corruption? If I understand SafeD correctly, that's its only goal. If it does more, I'd also argue casting to shared or immutable is, in general, unsafe. I'm also unsure if safeD has really fleshed out what would make use of (lockfree) shared variables safe. For example, array concatenation in one thread while reading in another thread could allow reading of garbage memory (e.g. if the length was incremented before writing the cell contents)