https://issues.dlang.org/show_bug.cgi?id=14125
--- Comment #28 from hst...@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. --
