Powershell: numeric-only parameter inconsistency

[iricigor]

PowerShell accepts parameters with numeric-only names in a function definition, but it is ignoring them while processing. It should either:

• throw definition error, or
• treat parameter properly.

Get-Help is also properly parsing syntax for the new function.

I gave below the example with switch parameter, but it is the same also with int. This is a valid bug in PS Core 7.0.0-preview.5, but I think this is legacy from Windows.

Steps to reproduce

Declare a function with numeric parameter

function p1([switch]$1) {if ($1) {'Yes'} else {'No'}}

Expected behavior

PS /home/iiric> p1
No
PS /home/iiric> p1 -1
Yes

Actual behavior

PS /home/iiric> p1
No
PS /home/iiric> p1 -1
No

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.0-preview.5
PSEdition                      Core
GitCommitId                    7.0.0-preview.5
OS                             Linux 4.4.0-18362-Microsoft #10000-Microsoft Fri Jun 21 11:23:00 PST 2019
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Screenshot

Please see the screenshot with a normal function and normal behaviour and problematic function also.

[vexx32]

Yeah, -<number> is interpreted by the parser as a negative number rather than a parameter name in this instance.

This isn't the only example; many parameter names can be used which are entirely unusable, especially when using ${variable} syntax, which allows for many otherwise illegal characters to be used.

e.g.,

function test { param([object] ${|UnusableParam}) Write-Output ${|UnusableParam} }
#is interpreted as "test -" and then throws a CommandNotFoundException on UnusuableParam that follows the pipe.
test -|UnusableParam Value

I think the best course of action is probably to create a PSSA rule that warns when such parameters are created, so users are aware ahead of time that they're making parameters that they won't be able to refer to.

Note that you _can_ refer to them via splatting, so it's not entirely an "illegal" parameter per se, just one you can't call directly:

# using the above function as the example
$params = @{ '|UnusableParam' = "hello" }
PS> test @params
hello

# using the original issue function as the example
$params = @{ '1' = $true }
PS> p1 @params
Yes

As a general best-practice recommendation, I'd advise not doing that for several other reasons, chief amongst them being it isn't particularly great for readability. 😄

[iricigor]

Thanks Joel. I confirm splatting p1 @params works as expected. I will open an issue/new feature request in PSSA.

What would you suggest about this issue here, close it or leave it and do some corrective action? Could Get-Help detect illegal characters? Or function declaration can do it and throw a warning?

[vexx32]

Not sure how feasible it is to throw warnings off function definitions, to be honest.

/cc @SteveL-MSFT you think that's worth looking into in these cases? 🤔

[SteveL-MSFT]

Seems like a bad practice to have switches with names that are just numbers as it's confusing reading such a script whether it is a negative number or a switch or a parameter. The PSSA rule is a good suggestion. Get-Help is doing the right thing by just looking at the cmdlet signature so I don't think it's worth changing that. The parameter binder could determine that the cmdlet doesn't accept any ints by position nor remaining args, so it could know that -1 is a switch, but it seems such an edge case I'd rather not spend time trying to make changes to the parameter binder and introduce some other bug.

[iricigor]

Thanks for responses. PSSA new feature request created.