--- Comment #48 from klickverbot <> 2012-06-04 11:24:10 PDT 
(In reply to comment #46)
> (In reply to comment #45)
> > If a @trusted function accepts a pointer, it must _under no circumstances_
> > access anything except for the pointer target, because it can be called from
> > @safe code.
> The point of @trusted is that it is treated as @safe, but can do unsafe 
> things.
>  At that point, you are telling the compiler that you know better than it does
> that the code is safe.
> The compiler is going to assume you did not access anything else beyond the
> target, so you have to keep that in mind when writing a @trusted function that
> accepts a pointer parameter.
> Off the top of my head, I can't think of any valid usage of this, but it
> doesn't mean we should necessarily put a restriction on @trusted functions. 
> This is a systems language, and @trusted is a tool used to circumvent @safe-ty
> when you know it is actually @safe.

Sorry, but I think you got this wrong. Consider this example:

void gun(int* a) @trusted;

int fun() @safe {
  auto val = new int;
  return *val;

Here, calling gun needs to be safe under _any_ circumstances. Thus, the only
memory location which gun is allowed to access is val. If it does so by
evaluating *(a + k), where k = (catalanNumber(5) - meaningOfLife()), that's
fine, it's @trusted, but ultimately k must always be zero. Otherwise, it might
violate the memory safety guarantees that need to hold for fun(). This is
definitely not �defined by the programmer, and not expressed in possible way to
the type system or the compiler�.

Makes sense?

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to