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 :(

Reply via email to