https://issues.dlang.org/show_bug.cgi?id=12857
David Nadlinger <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #4 from David Nadlinger <[email protected]> --- (In reply to Kenji Hara from comment #3) > I think that everything inside @safe function should be safe or trusted. > From the point of view, declaring @system function inside @safe is much > dangerous. By disallowing it, we can stop writing error-prone code. I'm opposed to this change as it gratuitously increases language complexity. The current behavior is neither dangerous nor error prone. To see this, consider the following variation of your original example: --- auto func() @safe { static int* ptr; if (!ptr) ptr = new int; *ptr = 42; // Write something to ptr. return &ptr; } void main() { auto pp = func(); func(); *pp = cast(int*)1; func(); // crash! } --- Here, it is clear that it's not returning the pointer from func() that is unsafe, but writing a random value to it in main(). There is nothing that conceptually separates leaking a reference to a value out of a @safe function via a return value or a ref parameter from defining a nested function and passing that on. To put it differently, what is dangerous in your examples is not what happens inside func(), but that you rely on manual, error-prone inspection of main() to evaluate correctness of the program. --
