What exactly does "@safe" mean?

[Maxim Fomin]

On Saturday, 1 June 2013 at 19:59:19 UTC, 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.

You completely get the point. Safe attribute does not guarantee 
safety, but blocks some practices which are supposed to be 
unsafe. Such characteristic raises several questions:

1) How strong are @safe commitments? I value them quite weak, 
because @safe function can call trusted and systems function 
indirectly.

2) How (un)safe are those practices which are still allowed? They 
are also unsafe and issue here is not trivial cases like 
dereferencing null.

Current type system has some holes, so any practice blocked in 
@safe can be achieved by employing type system holes (delegates, 
ref and lazy parameters). On the other hand, there is no point in 
using these holes - just do not make a function @safe if it 
cannot be. However there is still a problem of doing 
unintentional (especially memory) errors.

> 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...

Yes, @safe is not an interface feature (in a sense of delivering 
some guarantee). As it stands, it is a commitment to not to do 
some potentially unsafe actions. It is useful only in cases when 
user doesn't want do unsafe things and asks compiler for help in 
detecting some of them.

> 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)

Of course not.

> 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" ?

I think it is the same except what is listed in the spec. Nothing 
conceptually different.

> Ditto for member functions, when they operate on pointer 
> members. Can those be @safe?

What do you mean?

> Yeah, overall, I'm confused as to what "@safe" means from an 
> interface point of view :(