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

switch statement unexpectedly treats barewords as expandable strings #3668

Closed
mklement0 opened this issue May 1, 2017 · 5 comments
Closed
Labels
Issue-Discussion the issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif Resolution-No Activity Issue has had no activity for 6 months or more WG-Language parser, language semantics

Comments

@mklement0
Copy link
Contributor

mklement0 commented May 1, 2017

Note: It may be too late to change this behavior, or it may fall into Bucket 3: Unlikely Grey Area.
If the former, the pitfall discussed is at least worth documenting.

about_Switch states about the syntax of individual switch branches:

 "string"|number|variable|{ expression } { statementlist }  

The above suggests that an expression can only be used inside script blocks, but in practice you can also use (...)- and $(...)-enclosed expressions directly (e.g., (1 + 2)) and even method calls (e.g., $PSVersionTable.PSVersion.ToString()).

Surprisingly, however, a non-numeric unquoted token that doesn't start with ( or $ (and doesn't break parsing) is unexpectedly treated like an (expandable) string rather than as an expression:

Steps to reproduce

0 -eq [uint32]::MinValue

switch (0) {
 ([uint32]::MinValue) { $true }  # OK - (...) ensures use as expression
 default { $false }
}

switch (0) {
 [uint32]::MinValue { $true }  # !! condition treated as *string*
 default { $false }
}

switch ('[uint32]::MinValue') {
 [uint32]::MinValue { $true }
 default { $false }
}

Expected behavior

True
True
True
False

Actual behavior

True
True
False
True

That is, unquoted [uint32]::MinValue is interpreted the same way as '[uint32]::MinValue' in this case.

This is unexpected, given that it is reasonable to conceive of the branch conditions of a switch statement as the RHS of an expression along the lines of <switch-value> -eq <branch-condition>, and given that any unquoted token on the RHS of -eq is interpreted as an expression.

Environment data

PowerShell Core v6.0.0-alpha (v6.0.0-alpha.18) on Darwin Kernel Version 16.5.0: Fri Mar  3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64
@mklement0 mklement0 changed the title switch statement unexpectedly treats barewords as string literals switch statement unexpectedly treats barewords as expandable strings May 1, 2017
@iSazonov iSazonov added WG-Language parser, language semantics Issue-Discussion the issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif labels May 1, 2017
@msftrncs
Copy link
Contributor

PowerShell ISE makes this pretty easy to see what is going on, and I have implemented this in PowerShell/EditorSyntax#156. The condition is treated as an argument, not an expression. I think the documentation for this needs to be clarified, though not sure how.

image

Source: https://github.com/msftrncs/PwshReadXmlPList/blob/master/PList%20Reader.ps1

Copy link
Contributor

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.

1 similar comment
Copy link
Contributor

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.

@microsoft-github-policy-service microsoft-github-policy-service bot added Resolution-No Activity Issue has had no activity for 6 months or more labels Nov 16, 2023
Copy link
Contributor

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.

Copy link
Contributor

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Discussion the issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif Resolution-No Activity Issue has had no activity for 6 months or more WG-Language parser, language semantics
Projects
None yet
Development

No branches or pull requests

3 participants