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
