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
