[5.8] Introduce if/switch expressions #63378
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
(cherry picked from commit 4efc35a)
…lver arena (cherry picked from commit f3df7ab)
For a single expression closure, just use the expression as the body in the case where we're coercing to Void, as the return is already implied. This avoids crashing in `ClosureExpr::getSingleExpressionBody` with a double braced body. Surprisingly it seems nothing is currently calling `ClosureExpr::getSingleExpressionBody` after type-checking, so no test case, but later commits in this patch will exercise this case.
Split out brace element handling for a couple of walkers into a new function. The diff for this is best viewed without whitespace changes. This should be NFC.
Factor out some type-checking logic for ReturnStmt, including the conversion to FailStmt, into a request. We can then invoke this request from both the regular type-checking path, as well as during a pre-check of an expression.
Introduce SingleValueStmtExpr, which allows the embedding of a statement in an expression context. This then allows us to parse and type-check `if` and `switch` statements as expressions, gated behind the `IfSwitchExpression` experimental feature for now. In the future, SingleValueStmtExpr could also be used for e.g `do` expressions. For now, only single expression branches are supported for producing a value from an `if`/`switch` expression, and each branch is type-checked independently. A multi-statement branch may only appear if it ends with a `throw`, and it may not `break`, `continue`, or `return`. The placement of `if`/`switch` expressions is also currently limited by a syntactic use diagnostic. Currently they're only allowed in bindings, assignments, throws, and returns. But this could be lifted in the future if desired.
Look through `try`/`await` markers when looking for out of place if/switch expressions, and customize the effect checking diagnostic such that we error that `try`/`await` are redundant on `if`/`switch` expressions.
hamishknight
added
🍒 release cherry pick
hamishknight
requested review from
ahoppen,
bnbarham,
CodaFi,
DougGregor,
rintaro and
zoecarver
as code owners
This was referenced Feb 2, 2023
airspeedswift
approved these changes
Feb 2, 2023
ahoppen
approved these changes
Feb 3, 2023
zoecarver
approved these changes
Feb 3, 2023
Currently we only consider ParamDecls, but isolated conjunctions can reference external VarDecls too. This fixes a spurious "cannot reference invalid declaration" error when the result builder transform is disabled in the test case rdar104687668.swift. It also fixes the attached test case, where an if expression references a pattern var in a for loop. rdar://105080067
airspeedswift
approved these changes
Feb 6, 2023
|
🚢 |
amartini51
added a commit
to amartini51/swift-book
that referenced
this pull request
Feb 25, 2023
The test cases that exercise this feature include switches over a Bool
with just a true and false case.
swiftlang/swift#63378
This just follows the principle from the rest of Swift that switches
must be exhaustive -- it's not a special case here -- which is probably
why the SE proposal doesn't call it out like it does for 'if'
expressions needing an 'else' clause.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
5.8 cherry-pick of #63022
Introduce SingleValueStmtExpr, which allows the embedding of a statement in an expression context. This then allows us to parse and type-check
ifandswitchstatements as expressions. In the future, SingleValueStmtExpr could also be used for e.gdoexpressions.For now, only single expression branches are supported for producing a value from an
if/switchexpression, and each branch is type-checked independently. A multi-statement branch may only appear if it ends with athrow, and it may notbreak,continue, orreturn.The placement of
if/switchexpressions is also currently limited by a syntactic use diagnostic. Currently they're only allowed in bindings, assignments, throws, and returns. But this could be lifted in the future if desired.