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

[via Digitalmars-d-bugs]

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

--- Comment #73 from Andrei Alexandrescu <andrei at erdani.com> ---
(In reply to David Nadlinger from comment #71)
> (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?

Prolly some misunderstanding in the going back and forth.

> 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.

How in the world did you acquire that idea?

> In fact, I'm rather confident that I have a better
> understanding of @safe-ty than most other people. :)

This is fantastic. I think the right way to go here is to leverage your good
understanding in finding better solutions. It takes me all of three seconds to
look at std.file.read and figure out that's definitely a bad way to go about
things.

> You are just not seeing
> a part of the problem that is there, right now, in real world generic code.

Well here I'm again counting on your excellent understanding of the topic for
good explanations and proposed solutions.

I'm not being sarcastic. If you have a good grasp over the matter at hand,
there must be a way you can prove that by concrete proposals and solutions, as
in DIPs and code and great pull requests (as opposed to relativelt unproductive
general conversation). Even though I am not as creative as you, I'm pretty sure
I can identify a brilliant solution when I see it. I think you'd agree the code
that https://github.com/D-Programming-Language/phobos/pull/2963 fixes is quite
the opposite of it. Please do come with something better.

> 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.

For generic functions safety would be deduced (which is indeed an area that
needs improvement - a very high-impact potential). There is of course the
possibility of forking the implementations by using template constraints and
then using different attributes for the forks.

--