https://issues.dlang.org/show_bug.cgi?id=14125
--- Comment #74 from Walter Bright <bugzi...@digitalmars.com> --- (In reply to hsteoh from comment #68) > Then there's Andrei's PR that contains a 50+-line @trusted function. I had a > headache trying to figure out whether it was truly @trusted -- it's wayyyy > too big to be adequately reviewed in a satisfactory way. And this review > effort has to be incurred every single time somebody so much as touches a > single line in that function, because @trusted disables all compiler safety > checks and therefore we can never be too sure whether the change has > introduced subtle breakage in safety. See my review of std.array.join() upthread. The idea that one could mark a function with an unsafe interface as @trusted and thereby avoid having to check the rest of the code for safety is destroyed by that example. The rest was correct, but could not be checked for safety by the compiler. It had to be reviewed. The @trusted workaround only provided an illusion of safety. No work was avoided - extra work is caused because I no longer trust the code in std.array and it all needs reviewing again. I propose a review rule - functions of the following patterns will be automatically rejected by reviewers: 1. any function that trivially wraps a call to an @system function so it can be marked as @trusted. For example: @trusted void* trustedMalloc(size_t n) { return malloc(n); } 2. any function that is a trivial wrapper around an operation that would otherwise be flagged as unsafe, for example: @trusted void* incPtr(void* p) { return p + 1; } --