== Quote from Walter Bright ([email protected])'s article > 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.
Oh yeah, and now that it looks like D is getting annotations, can/should we make pure and nothrow annotations, i.e. @pure, @nothrow, for consistency?
