On Thu, 05 Nov 2009 13:33:09 -0500, Walter Bright
<[email protected]> 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
