I see a couple of issues with this approach.

First, I think this breaks a common scenario:

sleep -s 10

Basically any command that has exactly 1 parameter beginning with S would no longer be callable by specifying -s.

Second, a common parameter would also not work with non-cmdlet binding functions because common parameters are not added to those functions. I think it would be a mistake to introduce an alternative syntax for splatting that doesn't work everywhere, especially when the incorrect syntax might appear to work silently as is typically the case where $args collects the "extra" parameters.

@KirkMunro, successfully started retry of PowerShell-CI-static-analysis

First, I think this breaks a common scenario:

sleep -s 10

Basically any command that has exactly 1 parameter beginning with S would no longer be callable by specifying -s.

There were never any guarantees with non-alias shorthand for parameter names that such syntax will continue to work over time. Only parameter aliases can guarantee consistent syntax, and commands where it is very common to use that syntax would be better off assigning those aliases so that they do continue to work over time. For the specific scenario mentioned here, we can add a s alias for the -seconds parameter in Start-Sleep if that is a concern.

Don't get me wrong...I get the concern -- there is muscle memory to think about. That said though, shorthand parameter names don't always work from version to version because parameters are added to commands over time. I also recognize that this is a common parameter, so more invasive, vs. a command author adding a parameter and thinking to add aliases to support specific shorthand syntax as they add that parameter. The guarantee still isn't there though, unless aliases are used.

Second, a common parameter would also not work with non-cmdlet binding functions because common parameters are not added to those functions. I think it would be a mistake to introduce an alternative syntax for splatting that doesn't work everywhere, especially when the incorrect syntax might appear to work silently as is typically the case where $args collects the "extra" parameters.

You're right that this wouldn't work for basic functions. A rule should be added to PSSA to pick up on such things and warn users. If there isn't a rule already to identify when a basic function is passed common parameters, there should be, regardless of what happens with this PR. Your argument about common parameters appearing to work silently with $args collecting "extra" parameters isn't unique to the proposed -splat common parameter. It applies to all common parameters (-ErrorAction, -WarningAction, etc.). Users who create functions and who want common parameter support need to learn that CmdletBinding is required.

@KirkMunro, successfully started retry of PowerShell-CI-static-analysis

@KirkMunro, successfully started retry of PowerShell-CI-Windows

The only concern that I have is the name Splat:
PowerShell's parameters are usually not shortened but more importantly the word splatting/splat is a word that is not very intuitive/explanatory to someone that does not know about PowerShell splatting or is not a native English speaker.
I do not have a better name but it would be great to have a name that is more self-explanatory.
In Python they call it 'parameter unpacking'
https://www.python.org/dev/peps/pep-0448/

We could opt for something like -Parameters with a short alias -Params 🤔

We could opt for something like -Parameters with a short alias -Params 🤔

While I like the sound of it, I think -Parameters is too generic and would be a high risk for collision. For example, Get-Help has a -Parameter parameter. It would be confusing to have both -Parameter and -Parameters in any cmdlet. OTOH, the -Splat name is not likely to result in collision or confusion with other parameter names.

Since the concept of splatting already needs to be learned, I like the explicit nature of the -Splat name, myself. Plus, visibility of that as a word gives users something to search for so that they can learn what it does.

I should note, I did consider including @ as an alias for the -Splat parameter, but since PowerShell treats -@ as a positional value (it isn't recognized as a parameter name today), that would be a breaking change. I'm not opposed to making such a change, but I didn't want it in the first implementation of this PR.

How about -ParameterSplat? Or -SplattedParameter? Or -ParameterObject?

@KirkMunro, successfully started retry of PowerShell-CI-Linux

What about -PSArgumentList?

List is a type, that might be confusing. PS seems a bit redundant and not common for parameter names

We keep having discussions in various threads when adding common parameters how not to clobber existing parameters. It could have been avoided if a reserved prefix was used, like with cmdlets. It's slightly off topic for this specific PR but wanted to bring it up for the overall common parameter discussion.

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Mainainer, Please provide feedback and/or mark it as Waiting on Author

Closing.

no -splat, no -@, no @@ yet, will there be anything like that in the future? It seems like all approaches to improve splatting and thus usability are declined. Is there anything else in the work?