phobo's std.file is completely broke!

[Vladimir Panteleev]

On Wednesday, 19 September 2018 at 09:16:30 UTC, Nick Sabalausky 
(Abscissa) wrote:
>> Essentially they boil down to "it is impossible to prove the 
>> algorithm is correct" (for both detecting when the path fix is 
>> needed, and fixing the path).
>
> If you're referring to the inability to deterministically 
> reason about just what in the h*ll MS's API's actually do, then 
> I agree. But the problem is, it's equally true of all Win APIs. 
> Only way to fix that is to omit Win support entirely.

It's not our job to fix it. Just provide a D interface to it, 
which already we do well.

> Otherwise, I disagree. I think it is not only provable, but 
> also unnecessary to prove simply because such proof has never 
> been necessary for Phobos, and there is nothing inherent to 
> this problem which is inherently more complicated than anything 
> already existing in Phobos (you can even omit the questionable 
> modules like std.xml, it all still holds).

No, we are mucking with data on the way between the user's 
program and the OS, because we think we can fix it. Not only 
should we not be doing that in the first place, but even if we 
get it right, it might still not be what the user wants.

> Otherwise, present counterexamples demonstrating the inherent 
> ambiguity/non-provability.

I don't understand what you mean here.

>> Forcing the path transformation can introduce regressions,
>
> All phobos/compiler changes have the potential for regressions, 
> plus we have unittests. Unless you can demonstrate how this 
> necessarily goes above and beyond the risk from any other 
> change in a way that cannot be sufficiently mitigated by tests, 
> then the concern is irrelevant.

This might be a change which we won't be able to back out of if 
it turns out to be a bad idea, because then we break other 
classes of programs that depend on this change. See 
https://forum.dlang.org/post/eepblrtjmqzbtopylfib@forum.dlang.org 
for an example.

>> or make the situation worse on systems where it's not needed.
>
> Provide an example where the situation is made worse.

1. A user is happily using D on a system where the workaround is 
not needed.
2. A new D version comes out, with the workaround forcibly 
enabled.
3. The user's program is now broken.

If you provide a specific implementation for the workaround 
you're envisioning, I could try to come up with more specific 
situations where it would fail. There's been lots of reasons 
mentioned in this thread where things can go wrong, and surely 
there will be more that we can't think of ahead of time.