René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Treat `-Switch:$false` the same as omitting a switch when selecting a parameter set","articleBody":"### Summary of the new feature / enhancement\n\nNote:\n\n* The problem affects cmdlets that use `[switch]` parameters as _mandatory_ in the context of an explicit parameter set, such as `Get-UpTime`\n  * See #25015\n  * In short: What this issue proposes is to treat `-Switch:$false` as if `-Switch` had _not_ been specified, as these two forms should generally be equivalent, with the former often being used for _programmatically_ building arguments, especially via splatting.\n    * Indeed, checking `$Switch.IsPresent` yields `$false` in _both_ cases (for thoughts about the naming of this property, see [this comment](https://github.com/PowerShell/PowerShell/issues/25015#issuecomment-2659902287)).\n  * Currently, `-SomeSwitch:$false` acts the same as passing `-SomeSwitch` (i.e., implied `:$true`) in terms of _parameter-set selection_, which causes all cmdlets that only check whether the relevant parameter set was selected to in effect _ignore_ the `$false` argument.\n    * @MartinGC94's analysis [here](https://github.com/PowerShell/PowerShell/issues/25015#issuecomment-2659999347) shows that quite a few existing cmdlets misbehave in this way, and the proposal at hand would presumably automatically fix that.\n  \n* It is debatable whether this proposal should be considered a feature request or a bug report.\n \n* Either way, it is technically a breaking change, but - given the counterintuitive behavior and the presumed rarity of passing negated switches (`-SomeSwitch:$false`), it hopefully falls into [bucket 3](https://github.com/PowerShell/PowerShell/blob/master/docs/dev-process/breaking-change-contract.md#bucket-3-unlikely-grey-area)\n  * In the vast majority of cases, _omitting_ `-SomeSwitch` and passing `-SomeSwitch:$false` (which is the only way to emulate omitting the switch when _splatting_ is used, short of conditionally constructing the splatting hashtable iteratively) should be considered equivalent.\n  * (In edge cases, where  `-SomeSwitch:$false` is designed to override a default value set _elsewhere_, notably via a preference variable (e.g., `-Confirm:$false` overriding the `$ConfirmPreference` variable), a different approach is already necessary, namely if, in addition to `$Switch.IsPresent` returning `$false` (which _is_ the case when `-Switch:$false` is passed), whether this \"non-presence\" was _explicitly signaled_ via a `-Switch:$false` argument rather than being implied by omission.)\n\n\n\nTo illustrate the problem:\n\n```powershell\nfunction foo {\n  [CmdletBinding(DefaultParameterSetName='NoSwitchSet')]\n  param(\n    [Parameter(ParameterSetName='SwitchSet')]\n    [switch] $Switch\n  )\n  [pscustomobject] @{\n    SwitchValue = $Switch\n    ParameterSetName = $PSCmdlet.ParameterSetName\n  }\n}\n\n# Invocation without -Switch\nfoo \n# Invocation with negated -Switch, which _should_ be equivalent.\nfoo -Switch:$false\n# Ditto, via splatting\n$splat = @{ Switch = $false }\nfoo @splat\n```\n\nExpected / proposed behavior:\n\n```none\nSwitchValue ParameterSetName\n----------- ----------------\nFalse       NoSwitchSet\nFalse       NoSwitchSet\nFalse       NoSwitchSet\n```\n\nCurrent behavior:\n\n```none\nSwitchValue ParameterSetName\n----------- ----------------\nFalse       NoSwitchSet\nFalse       SwitchSet\nFalse       SwitchSet\n```\n\nThat is, the `-Switch:$false` invocations (whether directly or via splatting) unexpectedly still selected the `SwitchSet` parameter set.\n\n\n\n### Proposed technical implementation details (optional)\n\n_No response_","author":{"url":"https://github.com/mklement0","@type":"Person","name":"mklement0"},"datePublished":"2025-02-15T15:36:36.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":23},"url":"https://github.com/25027/PowerShell/issues/25027"}