On Sat, 01 Jun 2013 21:59:18 +0200 "monarch_dodra" <[email protected]> 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 :( Core dumps aren't the big problem @safe tries to avoid. The big problem is memory corruption, ie trampling memory you didn't expect to (or shouldn't be allowed to).
