Thoughts about breaking up the Splatting RFC into manageable chunks and revisiting the proposed syntax

The RFC for generalized splatting is currently in the Draft-Approved state, but not being implemented due to a combination of other priorities and complexities in the implementation.

While it's in this wait state, can I express some strong objections to what it proposes, and suggest that more thought is needed here? I can write these up as additional competing RFCs, but I don't want to go through that process if people just disagree with me, so I'll just share my issues with the RFC as it is today for now. And yes, this is opinionated, but I really feel that the syntax proposed in that RFC is making things much more difficult than they need to be. The details below suggest how it may be broken up and simplified, such that there aren't than many splatting-specific improvements needed at all.

Generalized Splatting is not the right way to solve the backtick issue

The Motivation section of the RFC highlights how backticks are not a great solution for multi-line continuance, and neither is splatting. Part of the solution to that problem, as proposed by the RFC, is inline splatting, yet inline splatting has its own issues:

• splatting uses a different syntax than normal use of parameters in a command invocation, and this inconsistency isn't necessary.
• conversion to/from splatted parameters or normal use of parameters is a nuisance, even if you have inline splatting.
• inline splatting can help multi-line continuance for command invocations, but it doesn't allow scripters to wrap other lines in a way that makes code easier to read and maintain (e.g. wrapping multiple method invocations with the dot-reference operator at the beginning of a line).

An alternative to inline splatting (and to getting rid of backtick in general, by allowing scripters to enable multi-line continuance) is described in this RFC proposal. It covers more scenarios, and can be implemented completely independent of splatting improvements.

Splatting expressions shouldn't need special syntax combining @ and $

The RFC proposes splatting the value of a variable using this syntax:

command @$PSBoundParameters

It is not clear what value that syntax offers in the RFC today.

If the intent is that we can support using members on a variable while splatting, why can't we support this less complicated syntax instead?

command @PSCmdlet.MyInvocation.BoundParameters

# or

Invoke-Something @obj.GetInvokerArgs()

As long as the result is a hashtable or an array, we should be able to just make the parser support those syntaxes, shouldn't we? They are unambiguous, and non-breaking. This is an actual splatting improvement that could be implemented as part of a splatting RFC.

Relaxed splatting

Does it even make sense to do this when you can just splat multiple separate hashtables into a command?

The only specific need I know of related to this is mentioned in the Modifying hashtables for splatting alternate proposal, where it would be useful to be able to splat part of a hashtable. For example, something like this:

# Splat all parameters but 'Force'
command @PSBoundParameters-['Force']
# Splat all parameters but 'Force' and 'WhatIf'
command @PSBoundParameters-['Force','WhatIf']
# Splat only the literal path and filter parameters
command @PSBoundParameters+['LiteralPath','Filter']

These aren't really specific to splatting though, they're just about having new index operators for collections that allow you to generate a copy of a collection that excludes certain indices (-[...]) or that only includes certain indices (+[...]). I would recommend that be handled in a separate RFC that could be implemented independently, and then added to splatting as part of the splatting RFC so that it supports those operators inline when splatting.

Splatting in method invocations

This section proposes passing in specific arguments to a method by name, like C# allows. That's a worthy addition to consider adding; however, instead of using a complicated syntax with @@{...} enclosures, how about the following syntax:

$str.SubString(2, length:2)

It's a non-breaking syntactical change, and it's much easier to type and read. The same rules would still apply (named arguments must be at the end).

This is not really splatting and could be proposed as a completely separate RFC and implemented independently of splatting.

Inizia leggendo RFC0002-Generalized-Splatting.md e la pull request 179 collegata. Confronta le modifiche proposte per lo splatting generalized, expression, relaxed e method-invocation, quindi documenta se debbano essere suddivise in RFC indipendenti e quale sintassi dovrebbe usare ciascuna; il lavoro è considerato completato quando viene presa una decisione della community, non quando viene realizzata un’implementazione.