[Issue 24750] escaping sliced stack arrays not detected

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=24750

Jonathan M Davis <issues.dlang at jmdavisProg.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |issues.dlang at jmdavisProg.co
                   |                            |m

--- Comment #2 from Jonathan M Davis <issues.dlang at jmdavisProg.com> ---
Well, I wouldn't expect an error in those examples, because foo isn't marked as
@safe (though if the compiler is able to see that it's definitively a bug, I
see no problem with it giving an error even with @system code).

More generally, what should be happening though is that slicing a static array
should give the same kind of error that taking the address of a local variable
does (and in the same circumstances). So,

---
void foo() @safe
{
    int[3] arr;
    auto slice = arr[];
}
---

should give an error similar to

---
void foo() @safe
{
    int i;
    auto ptr = &i;
}
---

which gives

---
test.d(8): Error: cannot take address of local `i` in `@safe` function `foo`
---

If the compiler is able to detect that the usage is actually memory-safe (like
it can with DIP 1000), then it makes sense for it to not give an error, but in
any case where it isn't smart enough to know for sure, it should give an error
in @safe code (since otherwise, it can't actually guarantee that the code is
memory-safe), and the situations where it's going to be able to do that should
be identical between taking the address of a local variable and slicing a
static array, because it's ultimately the same operation, just with a different
type.

And at this point, without DIP 1000, I would expect an error in any case where
you take the address of a local variable in @safe code (since without DIP 1000,
the compiler can't currently detect that no escaping occurs), so IMHO, we
should be doing the same with any code that slices a static array (be it
explicitly or implicitly), and until we do, it's a hole in @safe - though of
course, any such change would require a deprecation period if we don't want to
immediately break existing code.

--