Slicing static arrays should be @system

[Jakob Ovrum]

On Sunday, 4 November 2012 at 05:31:41 UTC, Jonathan M Davis 
wrote:
> I just thought that I should bring greater attention to
>
> http://d.puremagic.com/issues/show_bug.cgi?id=8838
>
> As it stands, I think that the slicing static arrays being 
> considered @safe is
> a major hole in SafeD's safety, and I think that it's one that 
> many of us
> aren't aware of. But there seems to be some resistance to 
> outright making the
> slicing of static arrays @system within that bug report, and I 
> recall similar
> resistance in the thread that prompted that bug report 
> (unfortunately, I don't
> remember what thread it was - somewhere in D.Learn I think).
>
> So, I was wondering what the general consensus on this was. 
> Should slicing
> static arrays be considered @system? I honestly don't see how 
> we could do
> otherwise without the compiler being way, way smarter at 
> detecting escaping
> references than is ever going to happen.
>
> Also, I really think that if we're agreed that this change 
> needs to be made
> that it should then be made sooner rather than later, because 
> it's going to
> break code which actually tries to use @safe.
>
> - Jonathan M Davis

Just as a note, if slicing static arrays cannot be @safe, then 
type-safe variadic functions can't be @safe either, as it 
essentially does the same thing, just implicitly:

     void foo(int[] a...)
     {
         // 'a' is a slice of stack memory when foo *isn't* called 
with an explicit array.
     }

The compiler does perform its simple escape analysis on such 
parameters, but as we know, it's not very smart.

I guess another solution to this particular case is to make it 
generate a dynamic array when foo is @safe, but I don't think 
anyone is excited about this option...

Then there's the scope parameter storage class. The compiler 
isn't very smart about scope parameters either.

So what do we do about all these related issues?