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?
