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/bqsjebjxuljlqusao...@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.
