Doesn't this approach of reversing the order break this pattern of coding common to ps1 scripts?

$script = '[CmdletBinding()]

param (

    # PS1 Script Parameter

    [Parameter()]

    [hashtable]

    $ParameterName

)

 

function Verb-Noun {

    [CmdletBinding()]

    param (

        # PS1 Function Parameter

        [Parameter()]

        [string]

        $ParameterName

    )

   

}

 

$ParameterName.'

 

TabExpansion2 -inputScript $script -cursorColumn $script.Length | select -expandproperty CompletionMatches

So, apparently VisitAssignmentStatement returns whatever is on the left: https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/engine/parser/TypeInferenceVisitor.cs#L977
This caused some issues in my first test [string]$TestVar = "";[hashtable]$TestVar = @{};$TestVar where the typeinference saw it like the ast returned 3 types (string, hashtable x2) which was obviously not correct. If I fix that so AssignmentStatements return nothing then it's incorrect when used inside parentheses like this: $Var1 = ($Var2 = ls) because in that case the AssignmentStatement does return something.

Patrick Meinecke (@SeeminglyScience) What's your thoughts on this? How do I fix this properly?

GitHub

PowerShell/TypeInferenceVisitor.cs at master · PowerShell/PowerShell

PowerShell for every system! Contribute to PowerShell/PowerShell development by creating an account on GitHub.

Doesn't this approach of reversing the order break this pattern of coding common to ps1 scripts?

Not this exact scenario because parameters are handled before variable assignments, so it will see the hashtable parameter before the other function parameter. But you are right that the approach isn't perfect. If you define a variable, and then a function like this:

[hashtable]$ParameterName=@{}
function Verb-Noun {
    [CmdletBinding()]
    param
    (
        [Parameter()]
        [string]
        $ParameterName
    )
}
$ParameterName.<Tab>

then it will see the function parameter instead of the script variable. I will need to look into that.

Mmmm tricky! I'm inclined to think that it should continue to infer the type on the RHS, but only of the closest assignment.

But then if you do

[string] $thing = 'something'
$thing = 10
$thing.<tab>

then you'll get int. And maybe that's fine but it sure doesn't feel good. The ideal thing would be if it looped through parents and looked through assignments to find the closest "declaration" but not recurse into the parent's children. That way you could avoid & { [string] $a = 10 }; $a = gci; $a.<tab> finding string.

Though even that's not necessarily perfect because then you'd miss declarations in a foreach loop. BUT you could argue that you should have the declaration outside of the loop, and it's fine to miss it in this case.

Sorry I got kind of ramble-y there, but does that make sense? Not in a "just go do that" kind of way, I'm still thinking over exactly what should be done, just kind of talking it out.

I found a simple solution, just add a special case for AssignmentStatements inside ParenExpressions. On a related note, do we have an official name for this: $Var1 = ($Var2 = ls). People on the internet call it "variable squeezing" but I haven't seen any official documents with this name.

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

I found a simple solution, just add a special case for AssignmentStatements inside ParenExpressions. On a related note, do we have an official name for this: $Var1 = ($Var2 = ls). People on the internet call it "variable squeezing" but I haven't seen any official documents with this name.

So Paren can force it in scenarios where it doesn't typically happen, but it's implicit with $var1 = $var2 = ls. I'm inclined to say the best solution would be to only look at the closest assignment prior to itself if that makes sense

This PR has 22 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Label      : Extra Small
Size       : +17 -5
Percentile : 8.8%

Total files changed: 2

Change summary by file extension:
.cs : +4 -5
.ps1 : +13 -0

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

I've reverted the changes related to the assignmentstatementast type inference. I will (probably) look into fixing it in the future but it doesn't belong in this PR.

🎉v7.4.0-preview.4 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes