phobo's std.file is completely broke!

[Ecstatic Coder]

On Saturday, 15 September 2018 at 23:06:57 UTC, Jonathan M Davis 
wrote:
> On Saturday, September 15, 2018 6:54:50 AM MDT Josphe Brigmo 
> via Digitalmars-d wrote:
>> On Saturday, 15 September 2018 at 12:38:41 UTC, Adam D. Ruppe
>>
>> wrote:
>> > On Saturday, 15 September 2018 at 10:57:56 UTC, Josphe Brigmo
>> >
>> > wrote:
>> >> Phobos *NEEDS* to be modified to work with these newer OS's.
>> >
>> > You need to look at the source code before posting. The code 
>> > for remove is literally
>> >
>> > DeleteFileW(name);
>> >
>> > it is a one-line wrapper, and obviously uses the unicode 
>> > version.
>> >
>> > https://github.com/dlang/phobos/blob/master/std/file.d#L1047
>>
>> It doesn't matter, the fact is that something in phobos is 
>> broke. Do you really expect me to do all the work? The fact 
>> that using executeShell or "\\?\" solves 90% of the 
>> problems(maybe all of them) proves that phobos is not up to 
>> par.
>
> Using std.file should be on par with using the Windows API from 
> C or C++. It doesn't try to fix the arguably broken behavior of 
> the Windows API with regards to long paths but requires that 
> the programmer deal with them just like they would in C/C++. 
> The main differences are that the std.file functions in 
> question use D strings rather than C strings, and they 
> translate them to the UTF-16 C strings for you rather than 
> requiring you to do it. But they don't do anything like add 
> "\\?\" for you any more than the Windows API itself does that.
>
> If you consider that to be broken, then sorry. For better or 
> worse, it was decided that it was better to let the programmer 
> deal with those intricacies rather than trying to tweak the 
> input to make it work based on the idea that that could have 
> undesirable consequences in some circumstances. On some level, 
> that does suck, but the Windows API does not make it easy to 
> make this work like it would on a *nix system without 
> introducing subtle bugs.
>
> If you find that the std.file functions don't work whereas 
> using the same input to the Windows API functions in C/C++ 
> would have, then there's a bug in the D code, and it needs to 
> be fixed, but if it acts the same as the C/C++ code, then it's 
> working as intended.
>
> - Jonathan M Davis

This attitude is unfortunately the cause of a lot frustration 
among cross-platform developers like me.

I chose D for my file scripting needs because it's a 
cross-platform language.

I expect that calling the function F on system X will work the 
same as calling that same function on system Y.

That's the contract in cross-platform programming.

Unfortunately D fails at being consistent.

I recently learned this lesson with my Resync tool.

No everybody wants the cross-platform to behave inconsistently.

For example, in the past I've implemented a proprietary 
cross-platform C++ game engine for Windows, PS2, Xbox and 
GameCube.

The games needed some tuning for the graphics, etc.

But code-wise, the engine made the games behave consistently 
across the different platforms.

This was all about making each method of each class behaving the 
same. As simple as that.

Indeed, on some platforms, the game engine also provided extra 
classes and/or methods to add some functionalities specific to 
these platforms.

But the common trunc was implemented (!) to behave the same. That 
was what our game developers expected...