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

[via Digitalmars-d-bugs]

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

--- Comment #28 from hsteoh at quickfur.ath.cx ---
I agree that what's happening with std.file needs to be fixed.

But still, the nagging issue is, how do we restrict the scope of @trusted
inside a function body? This is pertinent because your mechanical verification
of @safe hinges upon @trusted functions being actually trustworthy -- since
@safe code can call @trusted functions no matter how unsafe the latter are,
otherwise the mechanical verification proves nothing and is useless.

If I have a @trusted function that only performs 1 or 2 potentially unsafe
operations, I'd like to mark those specific operations as needing manual
verification, while the rest of the function body ought to be under the
scrutiny of the compiler under @safe requirements. The idea is, if somebody
else comes along later and changes the code, I don't want him to introduce new
unsafe operations to the function body -- at least, not without requiring the
use of the same markup that designates said operations as unsafe. In other
words, besides those 1 or 2 potentially unsafe operations, I want everything
else in the function to be mechanically enforced to conform to @safe
requirements. If any new unsafe operations are to be introduced to the
function, I want them clearly marked as such so that they can be thoroughly
scrutinized before the code change is accepted. Any new code that isn't thus
marked ought to be rejected by the compiler outright as a potential breach of
trust.

Otherwise, once a function is marked @trusted, a careless code change can
easily introduce safety violations without any warning, and then percolate
throughout the entire @safe system.

--