PowerShell-RFC Incremental Dynamic Parameter Bind

Summary

Incremental Binding: As RuntimeDefinedParameter objects are written to the output in the dynamicparam block, they are immediately bound if an argument is available. This behavior differs from the current state, where all parameters are bound after the entire dynamicparam block has executed.
Variable Creation: When a RuntimeDefinedParameter is bound, a variable with the name of that parameter should be created in the dynamicparam block scope. This makes the bound value immediately available for subsequent logic in the dynamicparam block.

I already have a PR with the required code changes: https://github.com/PowerShell/PowerShell/pull/20069

Example

For brevity, this example assumes a user-supplied New-Parameter function.

Function Get-EdgeUpdates
{
    param()
    dynamicparam
    {   
        $EdgeVersions = Invoke-RestMethod https://edgeupdates.microsoft.com/api/products
        # Emit a RuntimeDefinedParameter to the pipeline
        New-Parameter -Name Product -ValidValues $EdgeVersions.Product -Type ([string]) -Mandatory
        # $Product is immediately available for use
        if($Product)
        {
            $EdgeReleases = $EdgeVersions | ?{$_.Product -eq $Product} | select -Expand Releases # Beta,Stable,Dev,Canary
            New-Parameter -Name Platform -ValidValues ($EdgeReleases.Platform | select -Unique) -Type ([string]) -Mandatory # Windows,Linux,MacOS,Android
            if($Platform)
            {
                $EdgeReleases = $EdgeReleases | ?{$_.Platform -eq $Platform}                
                New-Parameter -Name Architecture -ValidValues ($EdgeReleases.Architecture | select -Unique) -Type ([string]) -Mandatory # x86,x64,arm64,universal
                if($Architecture)
                {
                    $EdgeReleases = $EdgeReleases | ?{$_.Architecture -eq $Architecture}                
                    New-Parameter -Name Version -ValidValues ($EdgeReleases.ProductVersion | select -Unique) -Type ([string]) -Mandatory    
                }
            }
        }
    }
    end
    {
    }
}

Oct 19 '23 22:10 dkattan

@SydneyhSmith When do things like this get reviewed? I would love to be part of the conversation.

Nov 17 '23 15:11 dkattan

@JamesWTruher can you see if the Engine WG can review this?

Jan 18 '24 17:01 SteveL-MSFT

@JamesWTruher can you see if the Engine WG can review this?

I'd really love to be a part of the conversation with the working group. This is a non-breaking change, only net new functionality but the last time they reviewed it I was told to create an RFC so I did.

Jan 18 '24 18:01 dkattan

@SteveL-MSFT Community call is tomorrow, still looking for feedback on this.

Feb 14 '24 18:02 dkattan

I would really really like to have this feature. So much easier to write and I have several use cases.

Feb 20 '24 21:02 IntegriComCalvin

Would love to see this in PowerShell it would open up some interesting and more complex use cases not possible with the current implementation.

Feb 20 '24 22:02 homotechsual

I could definitely find use in this, seems useful for complex multi-site automation tasks that may have a varying set of environments.

Feb 20 '24 23:02 gigacodedev

+1. Have some existing modules that use dynamic parameters which would be streamlined with this. This would also open the door for less confusion when it comes to writing user-driven PowerShell modules (i.e. a helper module for technical folks that are not necessarily PowerShell savvy). This would be awesome.

Feb 21 '24 02:02 noaht8um

+1 This would make it substantially easier to deal with situations such as the example, which likely has equal application in dealing with the mess of versions and channels of Office/Apps for Business/Enterprise besides Edge, in another Microsoft example.

This would be helpful in automating both with larger scripting toolsets and in adding better validation to more complex system admin and management scripts, so I support the change.

Feb 21 '24 05:02 dszp

Anything Darren writes generally makes my life easier as one of his customers. Please consider the changes and merge so many, MANY people can benefit from his recommendations. Thanks.

Feb 24 '24 01:02 immolate

I think this will add a lot of incentive for people to jump on dynamicparams. Currently, they don't seem to be as robust as one would assume for something called "dynamicparams".

Feb 24 '24 18:02 Dakota-LM

I think this will add a lot of incentive for people to jump on dynamicparams. Currently, they don't seem to be as robust as one would assume for something called "dynamicparams".

I 100% agree with this- it seems like Darren is the one trying to make the name true here