On Sunday, June 02, 2013 09:59:08 monarch_dodra wrote:
> 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:
> >> 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

I don't know. The function isn't doing anything unsafe in and of itself. foo _can_ be marked as @safe, because none of the operations that it's doing are unsafe. The problem is when the caller does something unsafe. So, maybe that's the answer. It's the caller which can't be marked as @safe, because it's doing something stupid. foo isn't doing anything unsafe, so it _can_ be @safe.

I think that part of the problem is the fact that @safety is generally viewed with the idea that unsafe stuff is called by safe stuff and not that unsafe stuff is called by safe stuff. And these cases under discussion are cases where the safe stuff ends up corrupting stuff if called from unsafe stuff.

So, maybe emplace should be marked as @trusted (assuming that it can't corrupt anything if called from an @safe function and that its safety does not depend on its arguments). It _is_ a bit of a tough topic though.

- Jonathan M Davis

On Sun, 02 Jun 2013 03:59:08 -0400, monarch_dodra <monarchdodra@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

On Monday, June 03, 2013 12:03:51 Steven Schveighoffer wrote:
> 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.

Nice analogy.

- Jonathan M Davis