phobo's std.file is completely broke!

[Jonathan Marler]

On Wednesday, 19 September 2018 at 06:11:22 UTC, Vladimir 
Panteleev wrote:
> On Wednesday, 19 September 2018 at 06:05:38 UTC, Vladimir 
> Panteleev wrote:
>> [...]
>
> One more thing:
>
> There is the argument that the expected behavior of Phobos 
> functions creating filesystems objects with long paths is to 
> succeed and create those files. However, this results in 
> filesystem objects that most software will fail to access 
> (everyone needs to also use the long paths workaround).
>
> One point of view is that the expected behavior is that the 
> functions succeed. Another point of view is that Phobos should 
> not allow programs to create files and directories with invalid 
> paths. Consider, e.g. that a user writes a program that creates 
> a large tree of deeply nested filesystem objects. When they are 
> done and wish to delete them, their file manager fails and 
> displays an error. The user's conclusion? D sucks because it 
> corrupts the filesystem and creates objects they can't operate 
> with.

I was wanting to reply with something similar:)

My 2 cents..whatever it's worth.  Vladimir has expressed most if 
not all the points I would have brought up.  Abscissa did bring 
up a good idea to help users support long filenames, but I agree 
with Vladimir that this should be "opt-in".  Provide a function 
in phobos for it, plus, it lets them cache the result AND 
infinitely better, the developer knows what's going on.  What 
drives me mad is when you have library writers who try to 
"protect" you from the underlying system by translating 
everything you do into what they "think" you're trying to do.  
This will inevitably result in large complex adaptation layers as 
both the underlying system and the front-facing API change over 
time with unwieldy maintenance burden.  An opt-in solution 
doesn't have this problem because you've kept each solution 
orthogonal rather than developing a translation layer that needs 
to be able to determine what the underlying system does or does 
not support.  This is a fundamental example of encapsulation, the 
filesystem library should be it's own component with the windows 
filesystem workaround being an optional "add-on" that the 
filesystem library doesn't need to know about.  This workaround 
could look like an extra function in phobos...or you could even 
write a module that wraps std.file and does the translation on a 
per-call basis.