On Friday, 27 February 2015 at 15:35:46 UTC, H. S. Teoh wrote:
@safe has some pretty nasty holes right now... like:
https://issues.dlang.org/show_bug.cgi?id=5270
https://issues.dlang.org/show_bug.cgi?id=8838
My new reference safety system:
http://forum.dlang.org/post/offurllmuxjewizxe...@forum.dlang.org
...would solve the above two bugs. In fact, it's designed
precisely for bugs like those. Here's your failing use case for
bug 5270. I'll explain how my system would track and catch the
bug:
int delegate() globDg;
void func(scope int delegate() dg) {
globDg = dg; // should be rejected but isn't
globDg();
}
If func is marked @safe and no attribute inference is permitted,
this would error, as it copies a reference parameter to a global.
However, let's assume we have inference. The signature would now
be inferred to:
void func(noscope scope int delegate() dg);
Yeah it's obviously weird having both `scope` and `noscope`, but
that's pure coincidence, and moreover, I think the use of `scope`
here would be made obsolete by my system anyway. (Note also that
the `noscope` bikeshed has been suggested to be painted `static`
instead -- it's not about the name, yet... ;-)
void sub() {
int x;
func(() { return ++x; });
}
Well I suppose this rvalue delegate is allocated on the stack,
which will have local reference scope. This is where you'd get
the safety error in the case of attribute inference, as you can't
pass a local reference to a `noscope` parameter. The rest is just
a foregone conclusion (added here for completion):
void trashme() {
import std.stdio;
writeln(globDg()); // prints garbage
}
void main() {
sub();
trashme();
}
The next bug, 8838, is a very simple case, I think:
int[] foo() @safe
{
int[5] a;
return a[];
}
`a`, being a static array, would have a reference scope depth of
1, and when you copy the reference to make a dynamic array in the
return value, the reference scope inherits that of `a`. Any scope
system would catch this one, I'm afraid. Mine seems like overkill
in this case. :-/
