RFC0002-Generalized-Splatting comments

[lzybkr]

Use this issue to comment on this RFC: https://github.com/PowerShell/PowerShell-Language-RFC/blob/master/1-Draft/RFC0002-Generalized-Splatting.md

[splatteredbits]

I don't like using + as the slice operator. The + operator means "take argument 1, combine it with argument 2, and return a new thing". In your examples, the meaning changes to "take argument 1, take parts of it out, and return a new thing". This is confusing and increases cognitive load: you have to remember this strange behavior.

I suggest creating new -take and -slice operators, e.g.

@{ 'fubar' = 'snafu' ; 'snafu' = 'fubar' } -take 'fubar'
@{ 'fubar' = 'snafu' ; 'snafu' = 'fubar' } -slice 'fubar'

Would return

@{ 'fubar' = 'snafu' } # take
@{ 'snafu' = 'fubar' } # slice

It could even be augmented to support arrays (not sure if it should take/slice by index or value):

@( 'a', 'b', 'c' ) -slice 1..2
@( 'd', 'e', 'f' ) -take 2,0

Would return

@( 'a' )
@( 'f', 'd' )

The example from the RFC would look like

Get-ChildItem @$($PSBoundParameters -slice 'Force') # Splat all parameters but 'Force'
Get-ChildItem @$($PSBoundParameters -slice 'Force','WhatIf') # Splat all parameters but 'Force' and 'WhatIf'
Get-ChildItem @$($PSBOundParameters -take 'LiteralPath','Path') # Only splat 'LiteralPath' and 'Path'

[KirkMunro]

I love that you're moving forward on improvements to splatting! I'll use the new splatting features heavily once they are implemented/released!

Now, some feedback about the RFC:

In the Specification section, when you say "which means splatting without the second '@' would be a breaking change", do you mean to say "if we were to allow inline splatting of a hashtable without the second '@', that would be a breaking change, so two '@''s are required for this to work"?

When we use splatting today, we can splat a variable that contains a hashtable without providing the leading '$' to indicate that it is a variable (in fact, that's how we have to do it because it's the only way it works). With the proposed improvements, at the end of the Specification section, you show the ability to use inline subexpressions to build the hashtable that will be splatted into the command (e.g. Get-ChildItem @$(Get-ChildItemArg)), and you also show splatting in a method that returns a hashtable. Both of these techniques use subexpressions. I understand that the leading '$' is required for subexpressions because otherwise you would be using array enclosures which would not be splattable, so like the previous point, you must use @$(...) when splatting in a subexpression. I hope, however, that you also allow for direct splatting of a property or of the results of a method without the leading '$' character, which is inline with how splatting works today (no '$' character is required). i.e. I would like to see this specification extended to support the following two scenarios:

# Splat a hashtable that is inside a property of an object
Invoke-Something @pscmdlet.MyInvocation.BoundParameters

# Splat a hashtable that is returned from a method
Invoke-Something @obj.GetInvokerArgs()

I don't think either of these being supported is an unreasonable request, because they would offer a more natural extension to the splatting that we have today.

For relaxed splatting, and all other sections in the remainder of the document, I'd prefer if the '$' symbol was only necessary when using subexpressions, as mentioned above. Please consider keeping the '$' supported but optional when you are splatting a variable (or a property of that variable or the results of a method on that variable).

For Splatting in switch cases, I personally find that one odd for splatting, and wish the splat prefix simply wasn't necessary. Since you can't pass an array into a switch statement as an array without it unwrapping unless you prefix it with a comma, not having to splat here would be greatly preferred (but I know, someone out there could be passing in an array to a switch statement with the ',' prefix so that it is compared as an array, and they could be using a statically defined array in their comparison, so it could be a breaking change. Regardless of those wishes, splatting seems awkward in this scenario, to me at least.

For Modifying hashtables for splatting, I prefer the alternate proposal suggestion of other operators, and wonder what operators you have in mind for that. +/- seems too confusing to me.

I'm really looking forward to this proposal coming to light, and hope these comments help move forward on this design.

[BladeFireLight]

Would the new splatting be usable with DSC resources?

[rkeithhill]

I like the proposed changes from a perspective of nice enhancements to splatting but when I see this particular scenario:

Update-TypeData @@{
    TypeName = 'MyCustomType'
    MemberName = 'MyCustomProperty'
    MemberType = 'NoteProperty'
    Value = 42
}

I can't help but wonder if we had a more reliable line continuation char (where it didn't matter if there was whitespace after it), if this particular scenario wouldn't be simpler as:

Update: realized that _ can be a valid command name. Sigh... back to backtick for now.

Update-TypeData `
    -TypeName MyCustomType `
    -MemberName MyCustomProperty `
    -MemberType NoteProperty `
    -Value 42

This way, I don't have to quote every argument. It is just passing parameters/args as normal.

[DerpMcDerp]

This proposal doesn't address all the desirable features in "Here is what a proper splatting proposal needs to do" on Allow splatting without an intermediate variable. Specifically:

1. It's missing the ability to splat inside a hashtable literal, e.g. @{ a = 1 ; @$foo }
2. It's missing the ability to specify lazily evaluated default values for hashtable slicing if keys are missing. The $hashtable + 'LiteralPath',@{Force = $true} syntax could be made to work to allow for missing values but unfortunately it wouldn't be lazily evaluated. Also, this slicing syntax couldn't work for array slicing since $array + 1,@{3 = $true} already means array concatenation.
3. It's missing the ability to let you use barewords for keys in hashtable slicing. i.e. there is no way to unquote the bar in $hashtable + 'bar'.
4. This proposal only talks about splatting hashtables to methods but what about splatting arrays to methods?

Also, this RFC weirdly has the restriction:

# Error, multiple splatted arguments
$str.SubString(@@{startIndex = 2}, @@{length=2})

Why should that be an error?

# Error, splatted argument is not last
$str.SubString(@@{length=2}, 2)

But what if the splatted argument is an array? Is it still required to be last?

[DerpMcDerp]

If splatting inside hashtable literals is allowed, relaxed splatting with @? should be made to work inside hashtable literals too, e.g.

$a = @{
    A = 1
    @?@{
        A = 2
        B = 3
    }
}
# $a -eq @{ A = 2 ; B = 3}

To let us work around PowerShell's "duplicate keys are not allowed in hashtable literals" error.

[Jaykul]

Any chance we can splat objects, so that

$foo | invoke-command

is the same as

invoke-command @?$foo

[Jaykul]

A slice operator as suggested by @splatteredbits is interesting (I think the semantics of -slice are wrong in that proposal -- usually when we slice an array we specify what to keep?). Maybe if we got a slice operator, PowerShell could get array slicing the way Python does it instead of the way it works now -- so that it's faster, and can increment in steps?

That is, I agree with @splatteredbits that the RFC proposal for $hash + $keys meaning the same things as... $hash - ($hash.keys -ne $keys) is really not intuitive, but I think you need different names for the proposed operators. Perhaps use -slice or -take to mean _keep_ing things, and use -strip or -remove or something for removing...

[KevinMarquette]

I love the idea of having more ways to spat operations. Having the option to splat $PSBoundParameters in a proxy function without removing some is currently lacking and would be great to have. That is such a common pattern that we should have a way to address it.

My only concern about using @ for all splat operations is that all those examples did not feel all that intuitive for people getting into PowerShell. I think it kind of makes the code less readable to them. Splatting already blows their mind. I would almost prefer something slightly more verbose that would be searchable.

What about the addition of a -splat operator and a [PSCustomSplatObject]. It would be very searchable and discoverable to a larger audience.

# Equivalent - but splatting an expression (the value of a variable) 
command ($PSBoundParameters -splat)


# Splat another expression - a hashtable
Update-TypeData (@{
    TypeName = 'MyCustomType'
    MemberName = 'MyCustomProperty'
    MemberType = 'NoteProperty'
    Value = 42
} -splat )

I would like it even better if it is something that can be pipped.

$PSBoundParameters -splat | command

This just feels more PowerShell. It would have to produce a new [PSCustomSplatObject] that the interpreter would identify and handle in a special way. It would act as if ValueFromPipelineByPropertyName was set for each property.

The relaxed splat could be -rsplat or -relaxedsplat.

I would also be ok if the -splat came before the expression instead just like how -not works

# Equivalent - but splatting an expression (the value of a variable) 
command (-splat $PSBoundParameters)

# Splat another expression - a hashtable
Update-TypeData ( -splat @{
    TypeName = 'MyCustomType'
    MemberName = 'MyCustomProperty'
    MemberType = 'NoteProperty'
    Value = 42
})

Treating the splat as a special [PSCustomSplatObject] object would introduce some unique opportunities for other advanced operations.

$options = $PSBoundParameters -splat
command $options
$options | command

More importantly, this is something that can be returned from a function.

#sample function
function Get-Options { [PSCustomSplatObject]@{startIndex = 2} }

# Get-Output returns a splatted object
command (Get-Options)

# Splat a hashtable defined outside the method call
$subStringArgs = @{startIndex = 2} -splat
$str.SubString($subStringArgs)

# Splat a hashtable defined inline in the method call
$str.SubString(@{startIndex = 2; length=2} -splat)

# Splat a function return object that is pre-splatted inline in the method call
$str.SubString(Get-Options)

This new splat object would act like a hashtable in every other way. It could just be a hashtable with a different object type name. We could call it a [PSCustomSplatObject] and even allow casting and creating hashtables with that type.

# Splat another expression - a hashtable
Update-TypeData [PSCustomSplatObject]@{
    TypeName = 'MyCustomType'
    MemberName = 'MyCustomProperty'
    MemberType = 'NoteProperty'
    Value = 42
}

Then we could alias @ to the [PSCustomSplatObject]. Then this would align nicely with the RFC. With the exception that best practices and script analyzer would recommend [PSCustomSplatObject].

[rkeithhill]

@KevinMarquette I don't know. Splatting is not required so folks don't have to use it. And you can't take out the current splatting mechanism so new folks are going to see the old style in scripts all over the place. I guess I don't see much value in introducing an alternate splatting mechanism. In fact, having multiple implementation just muddy the waters. That said, PowerShell excels at having multiple ways to do things. :-)

Whenever, I see $PSItem it bums me out a little. You don't see it much because most folks use $_ but when I do run across I find myself doing a double-take. :-)

[Jaykul]

Side note regarding @KirkMunro's comment about Splatting in switch cases*:

I personally find that one odd for splatting, and wish the splat prefix simply wasn't necessary. Since you can't pass an array into a switch statement as an array without it unwrapping unless you prefix it with a comma, not having to splat here would be greatly preferred (but I know, someone out there could be passing in an array to a switch statement with the ',' prefix so that it is compared as an array, and they could be using a statically defined array in their comparison, so it could be a breaking change. Regardless of those wishes, splatting seems awkward in this scenario, to me at least.

Since array comparisons don't work in PowerShell (i.e. two arrays are never equal unless they're actually the same reference), I don't think the "but I know" part of this statement is true. There's really no reason we would need to use splatting inside a switch to define an array of test cases which all have the same body. You could just change the switch statement clause to allow arrays as the "case" :

$Many = "A","B","C","D" 
switch($Many) {
"A" { "Primary" }
"B","C" { "Secondary" }
default { "Other" }
}