From e8a58ea42f473cfcaa1977c3efce08bdf99a0dbe Mon Sep 17 00:00:00 2001 From: Arseny Kapoulkine Date: Tue, 1 Jun 2021 15:45:43 -0700 Subject: [PATCH] Update if-expr RFC with mid-block return interaction (#43) We don't have mid-block return support yet and it's not clear if we will due to similar grammatical issues with this wrt function calls, but noting this for completeness (thanks @alexmccord for bringing this up) --- rfcs/syntax-if-expression.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/rfcs/syntax-if-expression.md b/rfcs/syntax-if-expression.md index 67004e1..3d2dfce 100644 --- a/rfcs/syntax-if-expression.md +++ b/rfcs/syntax-if-expression.md @@ -39,6 +39,8 @@ Studio's script editor autocomplete currently adds an indented block followed by Parser recovery can also be more fragile due to leading `if` keyword - when `if` was encountered previously, it always meant an unfinished expression, but now it may start an `if-expr` that, when confused with `if-end` statement can lead to a substantially incorrect parse that is difficult to recover from. However, similar issues occur frequently due to function call statements and as such it's not clear that this makes the recovery materially worse. +While this is not a problem today, in the past we've contemplated adding support for mid-block `return` statements; these would create an odd grammatical quirk where an `if..then` statement following an empty `return` would parse as an `if` expression. This would happen even without `if` expressions though for function calls (e.g. `return` followed by `print(1)`), and is more of a problem with the potential `return` statement changes and less of a problem with this proposal. + ## Alternatives We've evaluated many alternatives for the proposed syntax.