[Issue 12857] Don't allow declaring @system function inside @safe block

[via Digitalmars-d-bugs]

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

David Nadlinger <code at klickverbot.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code at klickverbot.at

--- Comment #4 from David Nadlinger <code at klickverbot.at> ---
(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.

--