Repository navigation
ValueFromRemainingArguments attribute should not be allowed on multiple parameters #4629
Description
By definition, using attribute ValueFromRemainingArguments on a parameter:
-
only makes sense on one parameter
-
which should either be unconstrained, or declared as an array.
Both At least the former condition should be enforced at parse time, because functions that violate these principles fail on invocation in the typical use case.
[As noted below, the must-be-unconstrained-or-array condition cannot be reliably enforced without preventing exotic, but legitimate use cases.]
Steps to reproduce
Define the following functions:
# Define *multiple* `ValueFromRemainingArguments` parameters, which makes no sense.
function Foo1 {
[CmdletBinding()]
param(
[Parameter(ValueFromRemainingArguments)]
$Rest1,
[Parameter(ValueFromRemainingArguments)]
$Rest2
)
'hi1'
}
# Define a `ValueFromRemainingArguments` parameter with a *scalar type*, which
# generally makes no sense, because the whole idea behind the attribute is to collect
# *multiple* arguments.
function Foo2 {
[CmdletBinding()]
param(
[Parameter(ValueFromRemainingArguments)]
[int] $Rest
)
}Then, assuming you can define them (which you shouldn't be able to), invoke them:
Foo1 a
Foo2 1 2Expected behavior
Parsing the function definitions should fail, because they violate the idea behind the ValueFromRemainingArguments attribute.
Actual behavior
# Foo1 was successfully defined, but cannot be invoked with positional arguments.
Foo1 : Parameter set cannot be resolved using the specified named parameters.
# Foo2 was successfully defined, but fails with more than 1 [int] argument.
Foo2 : Cannot process argument transformation on parameter 'Rest'. Cannot convert the "System.Collections.Generic.List`1[System.Object]" value of type
"System.Collections.Generic.List`1[[System.Object, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]" to type "System.Int32".
In fact, Foo2 even fails with a single [int] argument, because a ValueFromRemainingArguments parameter currently unconditionally returns a [List[object]] instance, even if only a single argument is bound - see #4625
Environment data
PowerShell Core v6.0.0-beta.5 on macOS 10.12.6
PowerShell Core v6.0.0-beta.5 on Ubuntu 16.04.3 LTS
PowerShell Core v6.0.0-beta.5 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
Windows PowerShell v5.1.15063.483 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
Activity
lzybkr commentedon Aug 21, 2017
Reporting an error with multiple
ValueFromRemainingArgumentsparameters makes sense - though it is an unlikely breaking change, and we have to be careful in the case of multiple parameter sets.Reporting an error on the parameter type is not as simple - e.g. there are many possible ways (including one dynamic way) we might convert the argument(s) to a random parameter type, meaning there might be scenarios we'd break if we weren't extremely careful. While I'm not too concerned about such cases, I such an error is only marginally useful, so I'm not sure I'd bother with this one.
mklement0 commentedon Aug 21, 2017
Understood re multiple parameter sets.
I also get that preventing use of a pointless type is not terribly important, but I thought it was an easy mistake to prevent. It sounds like it's not easy after all.
iSazonov commentedon Aug 21, 2017
Have GitHub ThrottleLimit to create new Issues? I'm tagging Issues at a slower speed than Michael Klement (@mklement0) creates. 😄
mklement0 commentedon Aug 21, 2017
😜
No worries; my output will slow significantly soon.
markekraus commentedon Aug 21, 2017
What about this scenario?
result:
Shouldn't that be allowed?
mklement0 commentedon Aug 21, 2017
Mark Kraus (@markekraus):
Thanks - your example is helpful in two distinct respects:
It shows an example of where a scalar type can make sense as a
ValueFromRemainingArgumentsparameter's type. (I think we were already in agreement, but it's nice to have a concrete example).It shows why the implementation detail of PS binding a
[List[object]]collection rather than a regular[object[]]array can be problematic - see A ValueFromRemainingArguments parameter by default invariably receives a [List[object]] collection rather than a scalar / PowerShell array ([object[]]), as appropriate #4625To illustrate the latter point:
To restore the expected equivalence, you'd have to define an additional constructor,
MyClass ([object[]]$Values){ ...[-]ValueFromRemainingArguments attribute should not be allowed on multiple parameters / on a scalar parameter[/-][+]ValueFromRemainingArguments attribute should not be allowed on multiple parameters[/+]microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.