On Sun, 02 Jun 2013 03:59:08 -0400, monarch_dodra <monarchdo...@gmail.com>
wrote:
On Saturday, 1 June 2013 at 22:15:00 UTC, Jonathan M Davis wrote:
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
provable @safe depends on the precondition that its parameters are valid
and @safe.
The easiest way to do this is to mark main as @safe. Then you can't go
unsafe.
As people have pointed out, there are bugs/holes. They need to be fixed.
@trusted should be used VERY cautiously. It basically says "I know this
is @safe, but the compiler can't prove it". These situations should be
very very rare.
Think of @safe functions as bricks. By themselves, they are solid and
will hold up a building well. But if you put them on top of garbage, they
will be as useless as cardboard.
-Steve
