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

[via Digitalmars-d-bugs]

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

--- Comment #68 from hsteoh at quickfur.ath.cx ---
(In reply to Dicebot from comment #66)
[...]
> Wrapper is marked @trusted incorrectly but that is intentional. @trusted
> here is not used to tell function can actually be trusted but to keep
> everything else plain @safe.

I think this is precisely what Walter & Andrei are objecting against.


> Alternative solution is to invert it:
> 
> S readText(S = string)(in char[] name) @trusted if (isSomeString!S)
> {
>     () @safe {
>         import std.utf : validate;
>         auto s = read(name);
>     } ();
> 
>     auto result = cast(S) s;
> 
>     () @safe {
>         validate(result);
>     } ();
> 
>     return result;
> }
> 
> Which also solves same problem but it result in creation of much more
> wrappers and makes reading the source even harder (even despite the fact I
> cheated here and used lambdas instead of nested functions).

This would be the pedantically-correct version of the code. However, it is even
worse in readability than the current code.

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.

Not to mention, if any line in the 50+-line function is a call to another
function, then every time any one of *those* functions change (e.g., they were
@safe before but now an unrelated PR has made them @system), you have to
re-review the whole 50 lines again. Plus ALL other @trusted functions that may
have called those functions. This is clearly impractical beyond trivial
textbook examples.

I would truly love to know how Walter/Andrei propose to solve this maintenance
nightmare, since I'm clearly missing something that's blatantly obvious to
them.

--