Reading the Windows PowerShell Language Specification Version 3.0 I stumbled upon curious example of variable splatting (listed in part 2.3.2 – Variables of the document) that I assumed shouldn’t work. The example partially defined Get-Power function that should raise the base number to the specified power. So I implemented the body of the function and tested how it works. And to my amezement It worked flawlessly. Here is the example function, and some calls to test if it works properly:

function Get-Power ($Base, $Exponent)
{
    #return x^y
    [Math]::Pow($Base,$Exponent)
}

#call normally by positioned parameters
Get-Power 5 3
# put arguments into an array and call with splatting
$values = 5,3
Get-Power @values

#call normally by named parameters
Get-Power -Base 5 -Exponent 3
# put arguments into a Hashtable and call with splatting
$hash = @{ exponent = 3; base = 5 }
Get-Power @hash

Until the PowerShell version 3 splatting the array (the first case) was equivalent only to calling the function with parameters by position, but not anymore, as shown in the second example. Splatting the hashtable remains equivalent to calling the function with named parameters.

Here is example of the new behavior. You define new function Get-PowerWrapper that calls the original function Get-Power by splatting the Args variable. The Args variable contains all arguments passed to the function in an array. The original command is called and the PowerShell ParameterBinding engine is inteligent enough to bind the correct items together (parameter Exponent to value 3), effectively calling the command with named parameters.

function Get-PowerWrapper { Get-Power @args } # arguments are in an array

Get-PowerWrapper –exponent 3 –base 2
Get-PowerWrapper –base 2 –exponent 3

In the example the positioning of the parametes varies but the result is still 8. In PowerShell version 2 the script would end with conversion type exception because the string ‘-exponent’ would be passed to parameter on position one in the called function (the parameter named Base – see the definition of the Get-Power function).
The change is quite subtle but it enables you to write quick wrappers for existing commands without reimplementing their interface (parameters). This is of course unsafe way to do it, and you cut yourself from code completion, but as prototyping tool it looks awesome.

function Get-ChildItemSafe {
	if (Test-Path @args)
	{
		Get-ChildItem @args
	}
}
Get-ChildItemSafe -Path C:\temp

Of course you have to use only the parameters that are common to all the commandlets called.

Note: Unfortunately I did not discovered how exactly the binding rules work, because creating an args-like array and splatting it to the command does not work - the names don't bind to the values correctly. But maybe it is a good thing because in that case you are better off defining appropriate hashtable to splat.