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

[via Digitalmars-d-bugs]

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

--- Comment #71 from David Nadlinger <code at klickverbot.at> ---
(In reply to Andrei Alexandrescu from comment #61)
> Well I just did - std.file does count for real-world code. It's just not
> right.

Hold on a second. I'm suggesting that trying to clean up the std.array
functions might lead to an insight or two (interplay between the need for
@system code and template attribute inference), and you reply by claiming that
std.file is bad code?

I never tried to convince you that all real-world code would unambiguously
benefit from finer-grained @trusted-ness. But there is a good amount of code
where, as I wrote earlier, "[its] conceptual equivalent is useful right now".
Generic range algorithms that do some @system optimizations internally, such as
std.array, are an example.

This discussion would be much easier if you didn't assume that I don't know
what I'm talking about. In fact, I'm rather confident that I have a better
understanding of @safe-ty than most other people. :) You are just not seeing a
part of the problem that is there, right now, in real world generic code.

Whatever the solution to this issue will be—nested functions as currently used
in parts of Phobos, @trusted lambdas, @trusted blocks or something else
entirely—, discussing design decisions doesn't make a lot of sense without a
good grasp of the problem domain.

I'm rather certain that you calling std.array a disaster area is a consequence
of that. So, please consider how the need for attribute inference might
influence the picture before we discuss this any further. Once we agree on a
non-disastrous solution for the cases where the safety of a function depends on
a template parameter we can discuss how we might or might not want to apply it
as a general coding guideline in situations like std.file.

--