Fold in rationale for making else branch mandatory in if-then-else expressions. (#426)

This has been discussed but just didn't get incorporated into the RFC.

rfcs/syntax-if-expression.md

@@ -20,7 +20,7 @@ Instead of `and/or`, `if/else` statement can be used but since that requires a s
 
 To solve these problems, we propose introducing a first-class ternary conditional. Instead of `? :` common in C-like languages, we propose an `if-then-else` expression form that is syntactically similar to `if-then-else` statement, but lacks terminating `end`.
 
-Concretely, the `if-then-else` expression must match `if <expr> then <expr> else <expr>`; it can also contain an arbitrary number of `elseif` clauses, like `if <expr> then <expr> elseif <expr> then <expr> else <expr>`. Note that in either case, `else` is mandatory.
+Concretely, the `if-then-else` expression must match `if <expr> then <expr> else <expr>`; it can also contain an arbitrary number of `elseif` clauses, like `if <expr> then <expr> elseif <expr> then <expr> else <expr>`. Unlike if statements, `else` is mandatory.
 
 The result of the expression is the then-expression when condition is truthy (not `nil` or `false`) and else-expression otherwise. Only one of the two possible resulting expressions is evaluated.
 
@@ -30,11 +30,27 @@ Example:
 local x = if FFlagFoo then A else B
 
 MyComponent.validateProps = t.strictInterface({
-	layoutOrder = t.optional(t.number),
-	newThing = if FFlagUseNewThing then t.whatever() else nil,
+    layoutOrder = t.optional(t.number),
+    newThing = if FFlagUseNewThing then t.whatever() else nil,
 })
 ```
 
+Note that `else` is mandatory because it's always better to be explicit. If it weren't mandatory, it opens the possiblity that someone might be writing a chain of if-then-else and forgot to add in the final `else` that _doesn't_ return a `nil` value! Enforcing this syntactically ensures the program does not run. Also, with it being mandatory, it solves many cases where parsing the expression is ambiguous due to the infamous [dangling else](https://en.wikipedia.org/wiki/Dangling_else).
+
+This example will not do what it looks like it's supposed to do! The if expression will _successfully_ parse and be interpreted as to return `h()` if `g()` evaluates to some falsy value, when in actual fact the clear intention is to evaluate `h()` only if `f()` is falsy.
+
+```lua
+if f() then
+    ...
+    local foo = if g() then x
+else
+    h()
+    ...
+end
+```
+
+The only way to solve this had we chose optional `else` branch would be to wrap the if expression in parentheses or to place a semi-colon. 
+
 ## Drawbacks
 
 Studio's script editor autocomplete currently adds an indented block followed by `end` whenever a line ends that includes a `then` token. This can make use of the if expression unpleasant as developers have to keep fixing the code by removing auto-inserted `end`. We can work around this on the editor side by (short-term) differentiating between whether `if` token is the first on its line, and (long-term) by refactoring completion engine to use infallible parser for the block completer.