X Tutup
The Wayback Machine - https://web.archive.org/web/20230329061736/https://github.com/PowerShell/PowerShell/issues/19402
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected behavior of AutomationNull in object initializers (hashtable or [pscustomobject]) #19402

Open
5 tasks done
mklement0 opened this issue Mar 24, 2023 · 2 comments · May be fixed by #19415
Open
5 tasks done

Unexpected behavior of AutomationNull in object initializers (hashtable or [pscustomobject]) #19402

mklement0 opened this issue Mar 24, 2023 · 2 comments · May be fixed by #19415
Labels
In-PR Indicates that a PR is out for the issue Needs-Triage The issue is new and needs to be triaged by a work group.

Comments

@mklement0
Copy link
Contributor

mklement0 commented Mar 24, 2023

Prerequisites

Steps to reproduce

In an array-type-constrained variable (as in expressions in general), AutomationNull is treated like $null; e.g.:

# Note: & { } is a simple way to return the AutomationNull singleton.
# OK: no error, and $null is assigned.
[string[]] $arr = & { }

By contrast, using AutomationNull in hashtable / [pscustomobject]-based object initializers fails:

class Example {
   [string[]]$LogMessage
}

$automationNull = & {}

# !! BREAKS: "Unable to cast object of type 'System.Management.Automation.PSObject' to type 'System.String[]'"
[Example] @{ 'LogMessage' = $automationNull }

# !! BREAKS differently: ""Type 'System.String[]' does not have a default constructor (Parameter 'type')""
[Example] [pscustomobject] @{ 'LogMessage' = $automationNull }

That the [pscustomobject]-based initialization breaks differently is surprising, and reminiscent of #19384 (comment)

Expected behavior

Two [Example] instances should be constructed, with $null in the .LogMessage property.

Actual behavior

Both initializations fail, albeit differently:

InvalidArgument: /path/to/script.ps1:13
Line |
  13 |  [Example] @{ 'LogMessage' = $automationNull }
     |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot create object of type "Example". Unable to cast object of type 'System.Management.Automation.PSObject' to type 'System.String[]'.
InvalidArgument: /path/to/script.ps1:16
Line |
  16 |  [Example] [pscustomobject] @{ 'LogMessage' = $automationNull }
     |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot convert value "@{LogMessage=}" to type "Example". Error: "Type 'System.String[]' does not have a default constructor (Parameter 'type')"

Error details

See above.

Environment data

PowerShell 7.4.0-preview.2

Visuals

No response

@SteveL-MSFT
Copy link
Member

The first case should treat AutomationNull the same as Null which would result in an empty string. The second case is completely separate due to pscustomobject type conversion.

@msftbot msftbot bot added the In-PR Indicates that a PR is out for the issue label Mar 27, 2023
@mklement0
Copy link
Contributor Author

@SteveL-MSFT, the second case may be technically distinct, but it should behave the same and is equally broken.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
In-PR Indicates that a PR is out for the issue Needs-Triage The issue is new and needs to be triaged by a work group.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants
X Tutup