@safe inference fundamentally broken

[Timon Gehr via Digitalmars-d]

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- at 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.