Safety, undefined behavior, @safe, @trusted

[Steven Schveighoffer]

On Thu, 05 Nov 2009 13:33:09 -0500, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Following the safe D discussions, I've had a bit of a change of mind.  
> Time for a new strawman.
>
> Based on Andrei's and Cardelli's ideas, I propose that Safe D be defined  
> as the subset of D that guarantees no undefined behavior. Implementation  
> defined behavior (such as varying pointer sizes) is still allowed.
>
> Memory safety is a subset of this. Undefined behavior nicely covers  
> things like casting away const and shared.
>
> Safety has a lot in common with function purity, which is set by an  
> attribute and verified by the compiler. Purity is a subset of safety.
>
> Safety seems more and more to be a characteristic of a function, rather  
> than a module or command line switch. To that end, I propose two new  
> attributes:
>
> @safe
> @trusted
>
> A function marked as @safe cannot use any construct that could result in  
> undefined behavior. An @safe function can only call other @safe  
> functions or @trusted functions.
>
> A function marked as @trusted is assumed to be safe by the compiler, but  
> is not checked. It can call any function.
>
> Functions not marked as @safe or @trusted can call any function.
>
> To mark an entire module as safe, add the line:
>
>     @safe:
>
> after the module statement. Ditto for marking the whole module as  
> @trusted. An entire application can be checked for safety by making  
> main() safe:
>
>      @safe int main() { ... }
>
> This proposal eliminates the need for command line switches, and  
> versioning based on safety.

I like how the attribute can be applied at different levels.  Sounds good  
to me.  Should you also be able to mark a whole struct/class as  
@safe/@trusted, since it's generally a container for member functions?

Care to define some rules for "undefined behavior?"

-Steve