| |
 | Posted by Jonathan M Davis |  Permalink Reply |
|
Jonathan M Davis 
| https://issues.dlang.org/show_bug.cgi?id=24750
Jonathan M Davis <issues.dlang@jmdavisProg.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |issues.dlang@jmdavisProg.co
| |m
--- Comment #2 from Jonathan M Davis <issues.dlang@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.
--
|
