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
Enable simple detection of [AutomationNull]::Value with -is [AutomationNull] #13465
Comments
I really like this proposal. The differences between True story: I worked at a company where the team who used PowerShell the most had as their team's chat description:
The concept of a
|
Any chance this is going to be looked at eventually? The current implementation makes zero intuitive sense, and I think the example below is a very a basic and common use case. What's the hold up 2 years on?
|
@CopaceticMeatbag This issue is about an easier way to detect autonull, not a change in the behavior. That behavior in particular is relied upon heavily so I would not expect it to change. On an unrelated note, this issue is missing a needs triage tag, adding so the Engine WG can discuss it. |
@SeeminglyScience yes I'm sorry I should've been clearer; I think I read through issue #9997 and don't understand how @bpayette 's comments make sense to nullify the whole discussion. E.g. "The intent was to make AutomationNull as invisible to script users as possible". Ok sure, but PS is returning an [AutomationNull] result to me, and I'm trying to confirm that, and the response is "you're not meant to use that"? So why return it then if I'm not meant to use it? Feels like the PS team is more than happy shifting the burden onto the end user as a 'fix' for this issue. |
The Engine WG discussed this yesterday and agree to go forward with my proposal laid out in It should also be noted that we decided that a type accelerator was not necessary as it's an uncommon scenario. |
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you. |
2 similar comments
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you. |
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you. |
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes. |
-is [pscustomobject]
) and Add -is $null and -isnot $null support to operators and Where-Object #10704 (-is $null
)Summary of the new feature/enhancement
Enable the following
-is
test to allow for a PowerShell-idiomatic detection of the[System.Management.Automation.Internal.AutomationNull]::Value
value that commands that output "nothing" technically output.In expression contexts
[System.Management.Automation.Internal.AutomationNull]::Value
is treated like$null
, but there are contexts where the distinction matters:In the pipeline:
Also, because the
switch
statement treats its operand as an enumeration, a[System.Management.Automation.Internal.AutomationNull]::Value
value causes the statement to be skipped altogether; that is, it is effectively ignored:Operators behave inconsistently with AutomationNull as the LHS (see #3866):
In short: Because
[System.Management.Automation.Internal.AutomationNull]::Value
causes observable differences in behavior from$null
, it must be discoverable.Proposed technical implementation details (optional)
Note: Strictly speaking,
[System.Management.Automation.Internal.AutomationNull]::Value
is of type[System.Management.Automation.PSObject]
, but treating it as an instance ofAutomationNull
would be a helpful "white lie", similar to the one-is
already tells when it reports a[psobject]
wrapper's.BaseObject
value's type as the type.However, @SeeminglyScience's proposed implementation here would actually resolve this issue, via a new, public
System.Management.Automation.AutomationNull
wrapper, for which an[AutomationNull]
type accelerator would have to be defined.The text was updated successfully, but these errors were encountered: