What exactly does "@safe" mean?

[monarch_dodra]

On Saturday, 1 June 2013 at 22:15:00 UTC, Jonathan M Davis wrote:
> On Saturday, June 01, 2013 23:41:32 monarch_dodra wrote:
>> OK. But by that standard, can't (mostly) anything be trusted?
>> What about something that writes garbage, to a memory location 
>> it
>> was *asked* to write to? Or if wrong usage of the function can
>> lead to an inconsistence memory state, but without "out of 
>> bounds
>> accesses"?
>
> When a programmer marks a function as @trusted, they are saying 
> that they
> guarantee that the function will not do anything to corrupt 
> memory. So, yes, a
> programmer could mark absolutely anything as @trusted - 
> including stuff that is
> blatantly unsafe and will do all kinds of nasty stuff - but 
> that's the
> programmer's fault.

Well, by "mostly", I did mean stuff that's not blatantly wrong. I 
don't usually write stuff with the express objective of 
clobbering memory.

But given the previous answers, I think I see why anything that 
should work can't be marked @safe.

>> But still, if I were to give emplace an "already constructed
>> object", it will happily clobber that object for me, leaking 
>> the
>> destructor, and possibly putting the program in an invalid 
>> memory
>> state.
>> 
>> Now, it was *my* fault for calling emplace with an already 
>> built
>> object, but it was the (@trusted) emplace that clobbered-it.
>
> Well, given that the safety of the operation relies on what's 
> being passed in,
> the operation itself can't reasonably be marked as @safe, 
> because you can't
> guarantee that the operation isn't going to corrupt memory.

But isn't that exactly the same as my "void foo(int* p) @safe{*p 
= 0}" example ? That relies on what is being passed in to 
guarantee safety :/

@confused