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
Comments
switch
statement unexpectedly treats barewords as string literalsswitch
statement unexpectedly treats barewords as expandable strings
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. Source: https://github.com/msftrncs/PwshReadXmlPList/blob/master/PList%20Reader.ps1 |
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
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. |
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: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
Expected behavior
Actual behavior
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
The text was updated successfully, but these errors were encountered: