On Thu, 12 Nov 2009 08:45:36 -0500, Jason House
<jason.james.ho...@gmail.com> wrote:
Walter Bright Wrote:
Jason House wrote:
> At a fundamental level, safety isn't about pointers or references to
> stack variables, but rather preventing their escape beyond function
> scope. Scope parameters could be very useful. Scope delegates were
> introduced for a similar reason.
The problem is, they aren't so easy to prove correct.
I understand the general problem with escape analysis, but I've always
thought of scope input as meaning @noescape. That should lead to easy
proofs. If my @noescape input (or slice of an array on the stack) is
passed to a function without @noescape, it's a compile error. That
reduces escape analysis to local verification.
The problem is cases like this:
char[] foo()
{
char buf[100];
// fill buf
return strstr(buf, "hi").dup;
}
This function is completely safe, but without full escape analysis the
compiler can't tell. The problem is, you don't know how the outputs of a
function are connected to its inputs. strstr cannot have its parameters
marked as scope because it returns them.
Scope parameters draw a rather conservative line in the sand, and while I
think it's a good optimization we can get right now, it's not going to
help in every case. I'm perfectly fine with @safe being conservative and
@trusted not, at least the power is still there if you need it.
-Steve
