https://issues.dlang.org/show_bug.cgi?id=12625
--- Comment #16 from ZombineDev <petar.p.ki...@gmail.com> --- (In reply to Jonathan M Davis from comment #14) > (In reply to ZombineDev from comment #12) > > Just to clarify - I'm talking about OP case. Slicing static arrays in > > general can be @safe with enough escape analysis - e.g. when the slice > > doesn't outlive the slicee. > > In theory, it colud be @safe in such a case, but the same can be said of > taking the address of a local variable, which is currently always @system. > The two cases are identical save for the fact that slicing a static array > gives you a pointer and a size_t in a struct rather than just a naked > pointer. So, they should be treated the same with regards to @safety and > what types of operations are legal. If that means that we get escape > analysis for both, then that's fine, but it would be inconsistent to do such > escape analysis on the slicing of static arrays and not taking the address > of a local variable. Yes, I agree. I meant escape analysis in general. > Regardless, barring the addition of such escape analysis, slicing a static > array should _always_ be @system where it's legal at all. And this bug > highlights a case where it shouldn't even be legal (and isn't legal with the > equivalent code that involves taking the address of the temporary instead of > slicing it). Yes, this OK as temporary solution. Unfortunately, it may be considered a huge breaking change for valid existing code, because it makes static arrays useless in @safe D. --
