https://issues.dlang.org/show_bug.cgi?id=12625
--- Comment #14 from Jonathan M Davis <issues.dl...@jmdavisprog.com> --- (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. 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). --