[suggested trap] should not use ValueFromPipeline with more than one param

[jazzdelightsme]

I didn't notice an existing trap covering pipeline input getting bound to multiple parameters. Repro:

function foo
{
    [CmdletBinding()]
    param( [Parameter( Mandatory = $false,
                       Position = 0,
                       ValueFromPipeline = $true )]
           [string[]] $P1,

           [Parameter( Mandatory = $false,
                       Position = 1,
                       ValueFromPipeline = $true )]
           [string[]] $P2
         )

    process
    {
        try
        {
            Write-Host "`$P1: $P1" -Fore Magenta
            Write-Host "`$P2: $P2" -Fore Magenta
        }
        finally { }
    }
}

'asdf' | foo

# Expected: input gets bound to one parameter...
# Actual: ...but it gets bound to /both/

# I guess the lesson is that you should never have ValueFromPipeline on more
# than one parameter in a given parameter set, but PS lets you do that.

[nightroman]

Thank you for the interesting case, I did not know about such a feature.
I would not call this a trap though... PowerShell works in the expected way,
i.e. exactly as the code is written.

This may be even useful in some scenarios. Nothing practical comes to my mind
yet but here is some contrived and weird but "maybe useful example":

# Both commands output:
# $P1: v1
# $P2: v2

'v2' | foo v1
'v1' | foo -p2 v2

In other words, I can choose what to pipe, P1 or P2.
It's kind of useful that PowerShell makes this possible.

[jazzdelightsme]

My mental model of parameter binding includes the concept of "conservation of parameters" (like conservation of mass/energy in the physical world). One input "thing" gets bound to one parameter. I cannot think of any other binding scenario (I mean I think the only other possibilities are "positional" and "named") where a single input object gets "duplicated" to more than one parameter.

For example, consider positional binding. Suppose foo were declared like this instead:

function foo
{
    [CmdletBinding()]
    param( [Parameter( Mandatory = $false, Position = 0 )]
           [string] $P1,

           [Parameter( Mandatory = $false, Position = 0 )] # NOTE: same position!
           [string] $P2
         )

    process
    {
        try
        {
            Write-Host "`$P1: $P1" -Fore Magenta
            Write-Host "`$P2: $P2" -Fore Magenta
        }
        finally { }
    }
}

If foo 'asdf' were bound via your "exactly as written" rubric, then parameter binding should succeed, and both $P1 and $P2 should have the value 'v1'. But of course that's not what happens: when PS sees two parameters that both can be bound at position 0, in the same parameter set, it gives up (it does not even try to use types to try to break the tie, even). So why should pipeline binding work differently?

You could come up with an analogous situation for named binding, even: suppose you tried to write foo -P 'asdf': The parameter name is ambiguous (could match -P1 or -P2): so does PS assign 'asdf' to both? No, it fails binding.

In short, while one could argue that this is simply the design of pipeline binding, I found it unexpected, and therefore considered it a candidate for a "trap", but I'm not sure what rubric you use to decide if something qualifies.

[nightroman]

I like the case and I do not mind to add it to the collection.
But I am trying to understand the nature of the "trap".

I do not understand why # Expected: input gets bound to one parameter....
Do we expect PowerShell to ignore the second ValueFromPipeline = $true?
Should not we rather expect it to fail like in the second example?

[nightroman]

I'm not sure what rubric you use to decide if something qualifies [as a trap].

Something like sane code that does not work as expected.

[MikeShepard]

I see what he's getting at. He expects that a particular pipeline input is only bound to a single parameter. I haven't ever had a reason to bind one to multiple parameters, but I could envision having two different parameters wiht different types that bound to the same parameter. If you needed the pipeline value to be "convertible" to both types, that would get it done. I don't know why you'd do it that way. On the other hand, there's nothing "wrong" with doing something "unusual". Unless you think this is a common error for someone to do, I don't see the need to add it. Just my opinion. :-)

…

On Mon, Apr 22, 2019 at 8:59 PM Roman Kuzmin ***@***.***> wrote: I'm not sure what rubric you use to decide if something qualifies [as a trap]. Something like sane code that does not work as expected. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABKI2IW76Z7I3YSP2EU5IN3PRZUQBANCNFSM4HHQXFRA> .

-- https://powershellstation.com

[jazzdelightsme]

Should not we rather expect it to fail like in the second example?

You're right; if it were to work as the other binding types, it should fail.

[nightroman]

I added the case to the collection, see ValueFromPipeline.