phobo's std.file is completely broke!

[Nick Sabalausky (Abscissa)]

On 09/19/2018 02:55 AM, Vladimir Panteleev wrote:
> On Wednesday, 19 September 2018 at 06:34:33 UTC, Nick Sabalausky 
> (Abscissa) wrote:
>> - Does it actually, necessarily perform those additional OS calls?
> 
> We need to expand relative paths to absolute ones, for which we need to 
> fetch the current directory.
> 

So in other words, NO, it does NOT necessarily perform additional OS 
calls. It ONLY performs an additional call if the given path is relative 
*AND* if we've decided to not simply reject too-long relative paths 
outright (which I'd be fine with as a compromise. At least it would be 
well-defined and enforced with a meaningful message.)

>> - Is it really?
> 
> Is what really what? If you mean the memory allocation, we do need a 
> buffer to store the current directory. We also need to canonicalize away 
> things like \..\, though we may be able to get away with it without 
> allocating.

So, in many cases, it's NOT really "a good deal of extra logic that 
performs additional OS calls and generates additional GC garbage".

>> - If it actually does, are those additional, necessarily OS calls 
>> prohibitively expensive?
> 
> They are certainly going to be less expensive that actual filesystem 
> operations that hit the physical disk,

Sounds like QED to me. Especially if the alternative is silently 
incorrect behaviour on an entirely realistic subset of cases. (Realistic 
enough that both the thread's OP and the bug report's OP each ran into 
purely by accident.)

>but it will still be an unwanted 
> overhead in 99.9% of cases.
> 

That's an extremely exaggerated figure, and we've already established 
that the overhead is minor and often able to be elided. Weighted against 
the cost of incorrect behaviour on a subset of non-rejected inputs, I'd 
say that's a very clear "Yes, please!"

The extreme minority of currently-hypothetical cases which require 
minimal overhead for individual file I/O operations are free to 
low-level optimize themselves as-needed. Correct behaviour should never 
be sacrificed for minor performance tweaks when the minor performance 
tweak can still be obtained through other means if absolutely necessary.

> In any case, the overhead is only one issue.
> 

What's the other issue(s)?