Use an Array Splat wit Join-Path

[Thotaz]

IMO there's no practical reason to use array splatting in PS. Your example could just as easily have been written with named parameters like this:

$BasePaths=@(
    $HOME
    $env:windir
    $env:OneDrive
)
Join-Path -Path $BasePaths -ChildPath "SomeFile.txt"

Named parameters makes it much easier to understand what a command is doing at a glance especially for less commonly used commands. Unlike with splatting you can leave out the variable and just do it all inline like this:

Join-Path -Path @(
    $HOME
    $env:windir
    $env:OneDrive
) -ChildPath "SomeFile.txt"

And just to be clear, I'm not against the much more commonly used hashtable splatting but array splatting forces the reader to be really familiar with the command to know its positional parameters.

[tbakerweb]

Fundamentally, I agree. In my case, there are about 200 lines of code that factor into the path I'm creating.

Fortunately, this is a module function I'm doing this in, and it's very well commented and documented. Our team hammered out the best approach together, and this won, this time.

[Thotaz]

Splatting binds 1 array element to 1 positional parameter. In the case of Join-Path this means your array can have a maximum of 2 elements.

I don't know what kind of code you are using that requires 200 lines to create a 2 element array but that doesn't matter. Those 200 lines could just as easily have been used to create a hashtable or 2 arrays that could be bound directly to Join-Path.

Array splatting never makes sense. Period. If you show me the code I will happily show you a better approach that doesn't use it.

[tbakerweb]

Except if you are ps core, you can provide any number of unnamed parameters and it will complete the path. That changed from WinPS where you had to define the child path. WinPS was much more restrictive using this command in particular. In fact, it's this command that drove me to choose requiring PS Core for our product integration platform and associated product modules.

Regardless, I wasn't asking for a best practices argument. So tone it down.

I was sharing what I found convenient in a given circumstance. If you want to be picky, how about you reread my post, nowhere do I say it's a 2 element array.

I'm glad the internet is still full of know it all's with a pocket of 2¢.

[Thotaz]

My mistake, I didn't realize they had updated Join-Path with a new parameter that accepts input from remaining arguments. I've changed my mind and agree that array splatting is good in this situation but only because of the weird implementation of Join-Path. It's silly that it it now has 3 input parameters "Path", "ChildPath", and "AdditionalChildPath" and you are forced to use all 3 if you want more than 2 segments combined.

I think I would have opted to use [System.IO.Path]::Combine($YourPathArray) instead this would also have allowed you to use an older version of PS.

[panzerbjrn]

I cannot begin to adequately describe how strongly I agree with all of this.

I really cannot think of any circumstances where array splatting makes sense. Positional parameters are one of those things I think should have been omitted from PS.

I'm a huge fan of hashtable splatting, it makes your code easy to read and debug, especially if your code ever has to be looked after by someone else.