PR Summary

Continuing the work that was started in PR #8938, this PR adds more implicit line continuance support to simplify scripting while further reducing the need for explicit line continuance using backtick. With these changes in place, users can span commands across multiple lines as long as the subsequent lines begin with named parameters or splatted collections.

Breaking Change Details

It is marked as experimental at the moment because it introduces a breaking change and there wasn't a better way to make it optional at this time. Before these changes, users could invoke a command whose name begins with a dash (-), or a named unary operator in a statement, even on a line immediately following another command.

For example, here is what can be done before these changes:

function -minus {
   'The -minus command was invoked.'
}
Get-Process -Id $PID
-minus # Invokes the -minus command

Get-Process -Id $PID
-split 'a b c d'

With this PR in place, and with the experimental feature enabled, here is what happens instead:

function -minus {
   'The -minus command was invoked.'
}
Get-Process -Id $PID
-minus # Identifies the '-minus' text as a named parameter for Get-Process (implicit line continuance)
& -minus # Invokes the -minus command using the required workaround

-minus # The workaround isn't necessary when you don't have a command on the contiguous, non-whitespace lines before this command

Get-Process -Id $PID
-split 'a b c d' # Identifies the '-split' text as a named parameter for Get-Process (implicit line continuance)

-split 'a b c d' # You can invoke named unary operators after commands by ensuring the parser recognizes them as new statements (which is done by placing a blank line before them)

While command names beginning with dash are virtually non-existent, to the point where I don't know if any exist in Windows or Linux (searches seem to indicate that dashes as the first character are problematic when it comes to file names on Linux, so maybe that's why), named unary operators are part of PowerShell and are used frequently. With that in mind, I've opened an RFC for discussion on possibilities because I believe this feature adds significant value that is worth considering, even if it remains only optional.

PR Context

This PR helps because PowerShell has many long commands (especially since some command names are over 60 characters long!), with many, many parameters, and users often want to span those commands across multiple lines in their scripts, but the only way to do that in PS 6.x and earlier is to use backtick or splatting. Neither of those should be necessary. Splatting has a purpose (passing in a common set of parameters to multiple commands), but splatting should not be the solution to more intelligent line wrapping within scripts. Instead, PowerShell can simply identify implicit line continuance automatically by looking at the subsequent lines to determine if they start with a named parameter or a splatted collection, and if so, tread them as part of the same command.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Change is not breaking
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed: #4303
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Experimental
  • The use of and testing of this feature requires enabling the following experimental features: PSImplicitLineContinuanceForNamedParameters