ValueFromRemainingArguments attribute should not be allowed on multiple parameters

[mklement0]

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 2

Expected 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)

[lzybkr]

Reporting an error with multiple ValueFromRemainingArguments parameters 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]

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]

Have GitHub ThrottleLimit to create new Issues? I'm tagging Issues at a slower speed than Michael Klement (@mklement0) creates. 😄

[mklement0]

😜

No worries; my output will slow significantly soon.

[markekraus]

What about this scenario?

Class MyClass {
    [int]$Value1
    [int]$Value2
    [int]$Value3
    MyClass ([System.Collections.Generic.List[Object]]$Values){
        $this.Value1 = $Values[0]
        $this.Value2 = $Values[1]
        $this.Value3 = $Values[2]
    }
}

function Foo2 {
  [CmdletBinding()]
  param(
    [Parameter(ValueFromRemainingArguments)]
    [MyClass] $Rest
  )
  $Rest
}

Foo2 10 20 30

result:

Value1 Value2 Value3
------ ------ ------
    10     20     30

Shouldn't that be allowed?

[mklement0]

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 ValueFromRemainingArguments parameter'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 #4625

To illustrate the latter point:

# The following *should* be equivalent to `Foo2 10 20,30`, but isn't
> Foo2 -Rest 10, 20, 30
Cannot convert the "System.Object[]" value of type "System.Object[]" to type "MyClass".
...

To restore the expected equivalence, you'd have to define an additional constructor, MyClass ([object[]]$Values){ ...

[microsoft-github-policy-service]

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]

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]

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]

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.