phobo's std.file is completely broke!

[Vladimir Panteleev]

On Wednesday, 19 September 2018 at 05:49:41 UTC, Nick Sabalausky 
(Abscissa) wrote:
> This actually leads to an interesting point. Let's change gears 
> for a moment to "API Design Theory"...
>
> Suppose you implement API function X which takes Y as an 
> argument. Question: Should X accept values (or types) of Y for 
> which X fails? Answer: Ideally, no. At least to the extent 
> realistically possible.
>
> So what should a well-designed function X do when faced with 
> known-to-be unsupported input Y?[1] Here are the 
> possibilities[2]:
>
> ([1] "Unsupported" is defined here as "for the given input, the 
> function does not correctly and successfully perform its 
> intended goal".)

I don't think that accurately describes the situation. 
Considering how there is now a toggle which changes the API 
implementation's behavior, the limitation is no longer really a 
part of the API, but a part of the implementation.

Consider, also, other implementations of the Win32 API (Wine and 
ReactOS), as well as possible future versions of Windows (which 
may do away with this limitation entirely).

> 1. Add support for input Y to function X.
> 2. Reject input Y (via either: abort, throw or static compile 
> error)
> 3. Accept input Y and allow one of the following to occur[3]: 
> Silently fail to perform the expected task, silently do the 
> wrong thing, or trigger an unclear error 
> (assert/exception/compile) from deeper in the callstack. ([3] 
> Note that which one of these three possibilities occurs is 
> dependent on function X's exact implementation details.)
>
> Of these three possibilities for a function X faced with 
> unsupported input Y, the first two options are (in theory) 
> acceptable[4]. The third possibility is absolutely not 
> acceptable [to the extent realistically possible.]

This is, again, flawed logic. It is unreasonable to expect what 
the implementation of the underlying API will do, because it is 
outside of our control. Consider that this discussion would have 
occurred just before Microsoft added the registry switch to allow 
long path names. The solution would have been "obvious"; the 
reality is that it is an implementation we do not control and can 
change in the future at whim. At best, we can treat the API at 
face value and don't attempt to work around implementation quirks.

Consider also the case of special filenames like "con" or "prn". 
Creating these using the standard API is not allowed, but this 
can also be bypassed with UNC paths. All the arguments in favor 
of making Phobos support paths longer than MAX_PATH (using the 
UNC prefix) seem to also favor detecting and supporting these 
reserved file names. But is doing so really Phobos' burden?

We simply cannot define our API in terms of what we think the 
underlying implementation supports or doesn't.

>> No, that's completely nuts!
>> A library, especially a standard library, should not introduce 
>> new limitations, but pampering over the limitations of the 
>> platform is not the right thing to do.
>
> This is debatable. Why, exactly, is pampering over 
> pre-Win10-v1607's maximum non-\\?\ filepath length a bad thing? 
> Exactly what problems does it cause?

https://forum.dlang.org/post/bqsjebjxuljlqusaobst@forum.dlang.org

>> If the platforms API is piling POS, there's nothing a sane 
>> library can do about.
>
> That is patently untrue. It might be true in specific 
> circumstances, but it is not generally true. If you believe it 
> to be true in this specific case, then please explain 
> *how*/*why* there is nothing the library can do about it.

It is not Phobos' job to work around quirks in implementations 
beyond our control which can change at any moment.

> The general rule of thumb is: "Typical situations should work 
> as expected, atypical situations should be possible."

Operating on paths longer than MAX_PATH is not a typical 
situation.