https://issues.dlang.org/show_bug.cgi?id=21565
--- Comment #16 from Paul Backus <[email protected]> --- (In reply to Steven Schveighoffer from comment #15) > > The whole point of @safe is to avoid code review. Otherwise it's a > glamorized linter. If you have to review @safe code to make sure things > outside the safe code are actually memory safe, then you have lost the > battle. I think this is probably the root of this misunderstanding. There is nothing in the spec (or the implementation) that *requires* you to limit your review to @trusted code. If your proof of memory safety is based on manual review of @safe code, then as far as the language is concerned, that's a perfectly valid proof. I agree completely that D should make it *possible* for the programmer to limit their checking to @trusted code (see: DIP 1035), and that @trusted code that relies on manual review of @safe code should be subject to close scrutiny. But I think it would be a step too far for the language spec to outright *forbid* anything that requires any manual review of @safe code--especially since there is no practical way the compiler could enforce such a restriction. --
