GeezerVison

Bodging a built version of this into VSCode, I think it makes sense to flag each parameter attributes so they all get a yellow squiggly. That said, if there's a way to emit a single DiagnosticRecord that has multiple extents, I'm happy to change it.

Multiple parameters accepting pipeline input by value doesn't make sense (to me at least - maybe I'm missing a use-case?).

You're right that most of the time someone does this, it's probably a mistake. But it is valid and there's a small use case of switching parameter sets based on the type of value received over the pipeline. So we can accept this as an optional rule, but it cannot be on by default.

Multiple parameters accepting pipeline input by value doesn't make sense (to me at least - maybe I'm missing a use-case?).

You're right that most of the time someone does this, it's probably a mistake. But it is valid and there's a small use case of switching parameter sets based on the type of value received over the pipeline. So we can accept this as an optional rule, but it cannot be on by default.

Thanks so much for looking at this Andy 😀

I don't follow currently and I'm keen to. If you've the time to explain that use-case, I'd really appreciate that. If not, don't worry I'll get this changed to optional as you suggest.

The rule checks that, at most, one parameter per set accepts pipeline input by value (my comment ommited "set"). So, if you're changing parameter sets based on the pipeline input - that's fine, you'd still only be accepting value binding on one parameter in that set?

function Test-ValueFromPipeline {
    [CmdletBinding()]
    param (
        [Parameter(ParameterSetName = 'One', ValueFromPipeline)]
        [string]
        $Parameter1,
        [Parameter(ParameterSetName = 'Two', ValueFromPipeline)]
        [int]
        $Parameter2
    )
    process {
        "$($PSCmdlet.ParameterSetName) was used."
        "Parameter1: $Parameter1!"
        "Parameter2: $Parameter2!"
    }
}

'8' | Test-ValueFromPipeline

# One was used.
# Parameter1: 8!
# Parameter2: 0!

8 | Test-ValueFromPipeline

# Two was used.
# Parameter1: !
# Parameter2: 8!

When multiple parameters accept pipeline input by value - binding without and with type coercion is attempted for each. If the binding succeeds for multiple parameters then you have the same data bound to multiple parameters? I guess one parameter could be a string and another could be an int, bound by coercion if the string is a valid integer?

Is the use-case you're talking about when coercion for one such type would fail? e.g. An int and a Process

function Test-ValueFromPipeline {
    [CmdletBinding()]
    param (
        [Parameter(ValueFromPipeline)]
        [System.Diagnostics.Process]
        $Parameter1,
        [Parameter(ValueFromPipeline)]
        [int]
        $Parameter2
    )
    process {
        "Parameter1: $($Parameter1.Name)!"
        "Parameter2: $Parameter2!"
    }
}

Get-Process -Name 'Code' | Select -First 1 | Test-ValueFromPipeline

# Parameter1: Code!
# Parameter2: 0!

1990 | Test-ValueFromPipeline

# Parameter1: !
# Parameter2: 1990!

You'd then make some check about $Parameter1 having a value and go from there with whatever logic?

If that's the case, why would the use of parameter sets not be encouraged? The 32 set limit? Complexity?

Patrick Meinecke (@SeeminglyScience) has the explanation (I was relaying it from a triage call).

Whelp, the auto accept-combined merge was incorrect (it looked right). Liam Peters (@liamjpeters) are you able to rebase this or otherwise fix the merge conflict?

Andy Jordan (@andyleejordan) My hero ❤️. Thanks for sorting that out - I didn't get time to look at it yesterday