On 06/05/2014 08:09 PM, Steven Schveighoffer wrote:
A quick example:
T[] getBuf(T)() @safe
{
T[100] ret;
auto r = ret[];
return r;
}
void main() @safe
{
auto buf = getBuf!int();
}
Note, the above compiles. An interesting thing here is that we have explicitly
marked getBuf as @safe. So what if we want to remove that? It STILL compiles,
because the compiler infers @safety!
AFAIK it's a well known problem.
This situation is very bad. I personally think that we need to make
slicing a stack-allocated array INVALID in @safe code,
This issue is not a fundamental problem with @safe, nor is it a matter
of personal opinion, this is simply a compiler bug.
and not let that
code be inferred safe. We have already demonstrated an easy way to make
an internal delegate that can be @trusted for one line. That should be
used to work around this limitation.
I propose that we start migrating towards making slicing of stack data
un-@safe, first by making it a warning, enabled with -w. Then making it
an error.
Thoughts?
The fundamental issue seems to lie in methodology and it is that @safe
is approximated by the DMD implementation from the wrong side. Instead
of gradually banning usage of more and more constructs in @safe, the
implementation should have started out with not allowing any constructs
in @safe code and then should have gradually allowed more and more
manually verified to be memory safe constructs.
