Fix #31368: joinpath works on collections of paths

[belamenso]

Implements @StefanKarpinski's proposition from #31368. joinpath(splitpath(x)) == x should now hold.

close #31368

[StefanKarpinski]

Thanks for updating this!

[StefanKarpinski]

A few tweaks to avoid the unconstrained joinpath(paths) signature and to generalize indexing so that indexed collections whose indexing doesn't start at 1 will work.

[rfourquet]

What is the rationale for returning path_separator here? Noting that joinpath() throws, and joinpath("a") == "a", doesn't contain a path separator.

[belamenso]

When extending the interface to collections I had to pick something for [] and ().
@StefanKarpinski stated clearly in #20912 that joinpath should not throw, I treat these errors as typechecking. As to why separator:

• Separator on both Windows and Unix systems is a correct path to the root of the current drive.
• Empty string is not a valid path on Unix.
• Returning the root of the current drive (/ on Unix and C:\ on Windows) requires looking at filesystem on Windows, then joinpath would behave differently depending on current working directory and would no longer be just a data manipulation function (joinpath should not throw. period. #20912 (comment)).

I don't have any better idea.

[rfourquet]

Ok. I interpret (I can be wrong!) "joinpath should not throw" as it shouldn't depend on the content of the string arguments. But joinpath() already throws (a MethodError), and I wouldn't be too worried that joinpath(()) also throws, and we keep the equivalence joinpath(a::Vector{String}) == joinpath(a...).
And you could define only one method taking string arguments as

joinpath(paths::AbstractString...)::String = joinpath(paths)

I'm not sure if I would prefer joinpath() or joinpath([]) to throw or to return something which is "neutral" for path joining, which would rather be the empty string than / (returning the empty string is not the same as throwing an error, even if the empty string is not a valid path).

[belamenso]

After some consideration and @rfourquet's comments I now support throwing here:

• this was the original author's intent, which can be seen in missing joinpath(),
• there doesn't seem to be any clear best candidate for return value,
• symmetry with joinpath(AbstractString...), which is now implemented as

joinpath(paths::AbstractString...)::String = joinpath(paths),

• joinpath doesn't seem to be used in many dynamic situations where [] might come up, it's usually applied to a pair of some directory variable and a filename string.

I modified the code accordingly.

[rfourquet]

I see that you updated the code according to my feedback, but again, my opinion is just my opinion :) Maybe @StefanKarpinski will have another take, let's wait for more feedback.

[jw3126]

Why not duck type this and accept any iterator instead of only tuple and AbstractVector?

[StefanKarpinski]

The single-argument joinpath is ambiguous between a single string-like argument which should be converted to a string and a single argument that iterates path components which should be iterated, converted to strings and joined with path separators. Suppose someone tries to call this on an exotic type that's meant to represent a string-like type that doesn't subtype AbstractString, then what? If this API was duck-typed, then it would try to treat the argument like a collection and iterate it and then join the results together as strings. That might work fine if the thing happens to iterate path components, but what if it iterates something else like individual characters or grapheme clusters (which are represented as strings)? It's much better to make this API clearly constrained without ambiguity: we know what to do if the argument is an array or a tuple. If people really want to call joinpath on other collections, we can add those in the future on an as-needed basis, but it just doesn't seem likely to be necessary.

[musm]

This should be ready to go. Anyone else want to quickly sign off?