[Issue 14125] @trusted nested helper functions in std.file

[via Digitalmars-d-bugs]

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

--- Comment #74 from Walter Bright <bugzilla at 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; }

--