[Issue 14125] std.file has gotten out of hand

[via Digitalmars-d-bugs]

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

--- Comment #24 from hsteoh at quickfur.ath.cx ---
If that's not how @trusted was intended to be used, then fine, fix it.

However, that still does not address Dicebot's concern about protecting against
future change, which I think is a far more important issue. Currently, other
than what's currently in std.file which apparently is not "proper use" of
@trusted, there is no way to indicate which part of a larger function body
actually contains the trusted operation. For the most part, trusted functions
tend to only have a small core that's actually trusted, and everything else
really ought to be enforced to be @safe. When reviewing the function, you want
to only look at the relevant part, instead of reading the whole thing,
otherwise nobody would bother reviewing any @trusted code, since it's too much
work. Which defeats the purpose of @trusted.

Furthermore, if the entire function body is @trusted, then any arbitrary change
can introduce more unsafe operations to the function without any warning, and
subtle bugs can creep into the code this way. This is the original rationale
for factoring these one-liners into @trusted local functions -- that forces the
main function body to conform to @safe requirements, and only those small core
bits that actually need to be @trusted are marked as @trusted. Or, put another
way, the "dung" construct you're railing against is a way of pointing out to
reviewers "this is the bit that requires @trusted, everything else is @safe and
you don't have to worry about that". It's a way of making the part that needs
@trusted stand out.

If this isn't "proper use" of @trusted, then fine, but we *do* need *some* way
of restricting the scope of what's allowed in a @trusted function, especially
in a large collaborative project like Phobos. Right now, marking the entire
function @trusted is basically a free-for-all license that whatever garbage
code you wish to throw into this function, you can do it and @safe code will
still continue to work (even though it shouldn't).  I mean, come on, if there's
a large PR that touches 50 files and makes 5 changes in several 500-line
functions, are you seriously expecting reviewers to have to read the entire 500
lines *and* understand all of its subtleties, just because it's @trusted? Most
likely what will happen is that unsafe code will slip in without anyone
noticing, and before you know it, the function is completely unsafe yet it's
still marked @trusted. For this reason, @trusted needs to be kept as restricted
as possible.

--