What exactly does "@safe" mean?

[Jonathan M Davis]

On Saturday, June 01, 2013 21:59:18 monarch_dodra wrote:
> The way I understood it, @safe defines a list of things that are
> or aren't legal inside the implementation of a function. It also
> changes the scheme of bounds checking, in release code.
> 
> What bothers me though, is that from an interface point of view,
> it doesn't really mean anything (or at least, I haven't really
> understood anything). AFAIK: if I call something "@safe", chances
> of a core dump are relatively "lower", but they can still happen:
> * A function that accepts a pointer as an argument can be marked
> safe, so all bets are off there, no, since the pointer can be
> dereferenced?
> * Member functions for structs that have pointers, too, can be
> marked safe...
> 
> Or does it only mean "if you give me valid pointers, I can't core
> dump*"?
> (*ignoring current flaws, such as escaping slices from static
> arrays)
> 
> The main reason about this question is that now I'm confused
> about @trusted: what are the conditions a developer needs to take
> into account before marking a function "@trusted" ?
> 
> Ditto for member functions, when they operate on pointer members.
> Can those be @safe?
> 
> Yeah, overall, I'm confused as to what "@safe" means from an
> interface point of view :(

@safe is for memory safety, meaning that @safe code cannot corrupt memory. You 
can get segfaults due to null pointers and the like, but you can't have code 
which writes passed the end of a buffer, or which uses a freed memory, or does 
anything else which involves writing or reading from memory which variables 
aren't supposed to have access to.

Assuming that there are no bugs in @safe, the one thing that can invalidate it 
is @trusted. With @trusted code, it is the _programmer_ who is then 
guaranteeing that the code is actually @safe. The code is doing something 
which is potentially not safe (and therefore is considered @system by the 
compiler) but which _could_ be safe if the code is correct, and if the 
programmer is marking the code as @trusted, they are then telling the compiler 
that they've verified that the code isn't doing anything which could corrupt 
memory. As long as the programmer doesn't screw that up, then any @safe code 
calling that @trusted function is indeed @safe, but if the programmer screwed 
it up, then you could still get memory corruption. However, here's really no 
way to get around that problem with a systems language, since most code needs 
to eventually call something that's @system (e.g. all I/O needs @system stuff 
internally). But by limiting how much code is @system or @trusted, most code 
is @safe with a minimal amount of code having to have been verified by an 
appropriately competent programmer as being @trusted.

- Jonathan M Davis