Skip to content

Explicit creation of preference variables in descendant scopes should be appropriately type-constrained, as in the global scope / according to the definition of the preference variable #3483

@mklement0

Description

@mklement0

Currently, preference variables, such as $VerbosePreference, are only predefined in the global scope, where they are type-constrained, such as to [System.Management.Automation.ActionPreference], which ensures that only valid values can be assigned to them.
Some preference variables, such as $OFS, aren't even predefined in the global scope, although their type (and default value) is known, as described in Get-Help about_Preference_Variables.

By contrast, assigning to a preference variable in any descendant scope implicitly creates a new variable that is not type-constrained, which effectively allows assigning invalid values.

Therefore, assigning invalid values in scripts may go unnoticed.
(It seems that PowerShell quietly applies a given preference variable's default value in the event of encountering an invalid value.)

Steps to reproduce

$VerbosePreference = 'ThisIsAnInvalidValue'
& { $VerbosePreference = 'ThisIsAnInvalidValue' }

Expected behavior

Ideally, both commands would complain about the inability to convert string 'ThisIsAnInvalidValue' to type [System.Management.Automation.ActionPreference]

Actual behavior

  • The first command fails, as desired, because the top-level $VerbosePreference is type-constrained to [System.Management.Automation.ActionPreference], and converting string 'ThisIsAnInvalidValue' to that type fails.

  • The 2nd command is quietly accepted, because assigning to $VerbosePreference in the child scope created by & implicitly creates a new, local variable that isn't type-constrained, so it effectively becomes a [string] value that cannot be converted to a legal [System.Management.Automation.ActionPreference] value.

Environment data

PowerShell Core v6.0.0-alpha (v6.0.0-alpha.17) on Darwin Kernel Version 16.5.0: Fri Mar  3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64

Metadata

Metadata

Assignees

No one assigned

    Labels

    Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifIssue-Enhancementthe issue is more of a feature request than a bugResolution-No ActivityIssue has had no activity for 6 months or moreWG-Languageparser, language semantics

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions