GeezerVison

I think this is a bucket 2 breaking change, so maybe we need an RFC.

Dongbo Wang (@daxian-dbw) - can you review?

If someone's depending on this difference in behavior between Do-Something 1 2 3 and Do-Something 1,2,3, I want to give that person a stern talking-to. :)

as shown by the discussion about Write-Output, the change to HandleRemainingArguments in this PR would be a breaking change.
another example would be when an array of string can be converted to a specific element type of the parameter type:

class dummy {
    [object] $Path
    [object] $Name
    dummy ([object[]] $a) {
        $this.Path = $a[0]
        $this.Name = $a[1]
    }
    [string] ToString() {
        return ($this.Path + " -- " + $this.Name)
    }
}


function Test-Attribute
{
    param(
         [string[]]
         [Parameter(Position=0)]
         $Path,

         [dummy[]]
         [Parameter(ValueFromRemainingArguments)]
         $Extra
         )


     $Extra.Count;
     for ($i = 0; $i -lt $Extra.Count; $i++)
     {
        "${i}: $($Extra[$i].GetType().FullName) $($Extra[$i])"
     }
}

PS D:\> Test-Attribute root aa,bb
1
0: dummy aa -- bb
PS D:\>
PS D:\> Test-Attribute root aa bb
Test-Attribute : Cannot process argument transformation on parameter 'Extra'. Cannot convert value
"System.Collections.Generic.List`1[System.Object]" to type "dummy[]". Error: "Cannot convert the "aa" value of type
"System.String" to type "dummy"."
At line:1 char:1
+ Test-Attribute root aa bb
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Test-Attribute], ParameterBindingArgumentTransformationException
    + FullyQualifiedErrorId : ParameterArgumentTransformationError,Test-Attribute

Another proposal of the fix:
If the parameter is declared with ValueFromRemaningArgument and Position, and valueFromRemainingArguments.Count == 1, then we use the specified argument directly instead of wrapping it in a List.

When Position is specified, I assume the author would like do-something aa to be interpreted as do-something -param aa instead of treating aa as remaining arguments.

This won't solve the problem to parameters with ValueFromRemaningArgument but without Position, and also would require Write-Object to be changed -- remove Position=0 from the parameter declaration of InputObject. So this would also be a breaking change.

Fixing parameter binder bugs is very tricky. It would be so easy to break existing behavior.

The more I play with this, the more I think it's the existing behavior that's broken. I'd advise people not to declare ValueFromRemainingArguments parameters at all, in the current form.

Let me get more data about the usage of ValueFromRemainingArguments and Write-Output. Will reply back here.

IMHO, this behavior of Write-Output is pretty intuitive -- when -NoEnumerate is specified, give me back what ever items I gave you. In case of a b c, I gave you 3 items, so 3 items should be returned by Write-Output; in case of a,b,c, I gave you 1 item, which is an array, so the same item should be returned back.

Dave Wyatt (@dlwyatt) I'm not a good person to explain the parsing (maybe Bruce Payette (@BrucePay) can weigh in) but in this example, the parser views this as 1 parameter - an array with 3 values.

Or in this example:

Do-Something 1 2 3
This has 3 parameters with one value each.

Do-Something 1,2,3
This has 1 parameter with 3 values.

I don't see any value in breaking existing semantics but we could consider adding a new attribute [CollapseAllArgumentsIntoASingleArray](name TBD)
That seems like a bad thing because cmdlets with positional parameters are, and need to be, precise.
So a change like this would yield a unpredictable UX.

Jeffrey Snover (@jpsnover) : That's exactly what ValueFromRemainingArguments is supposed to do already. It's the equivalent of declaring params string[] someParam in C#. There are just some implementation quirks that cause it to not behave the same way when one syntax or the other are used.

We have discussed this and would like more data about potential breakage if we took the change.
We'll leave this open until somebody (likely us) do that work.

When you import the temporary module, the assembly is in use until PowerShell exits. That's why I don't create it in TestDrive:, and why I use the same file name every time (so we're not littering the test system with multiple dlls).

Dave Wyatt (@dlwyatt) Thanks for clafify!
We use temporary modules in several tests and we never cared about unloading them. That's why I'm surprised we're doing this here.

Just rebased. Will check back in a bit to make sure the tests are still passing.

Dave Wyatt (@dlwyatt) Thank you! This will be the last rebase for sure 😄

Dongbo Wang (@daxian-dbw) Should we add Docs-Needed and remove Review-Needed?