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