Unified Condition Expressions

Idea

Replace the different syntactic forms of

if expressions,
pattern matching and pattern guards,
if-let constructs

with a single, unified condition expression that scales from simple one-liners to complex pattern matches without requiring to switch to different syntactic constructs/keywords/...

This is done by recognizing the commonalities of if and match and pushing differences further down into the individual parts of the expression:

Conditions can be split between a common discriminator and individual cases. ... is used to indicate this.
A pattern matching operation can be signaled within the specific branch it is done; it does not require switching the whole syntactic from from if to match. is is used to indicate this.

I picked the if keyword over match because it is keyword the largest number of developers are familiar with, though the exact choice of keyword is not as important as ending up with a single one instead of the current two (if and match).

Out of scope

The intention is to cut the different syntax options down to a single one that is still easily recognizable by users. Minimizing keywords (i. e. a == b ? c : d) or turning conditions into methods (like Smalltalk) is not a goal.

Examples

// existing syntax, no change:
if true { 1 } else { 2 }

// using x for multiple, different comparison operations:
if x
... == 1 { "a" }
... == 2 { "b" }
... != 3 { "c" }
else { "d" }

// method calls:
if string
... .startsWith("abc") { x }
... .size == 3 { y }
else { z }

// pattern matching:                 (match syntax for comparison)
if type                                match type {
... is Type::Unit { "Unit" }             Type::Unit => "Unit",
... is Type::Bool { "Bool" }             Type::Bool => "Bool",
... is Type::Int64 { "Int64" }           Type::Int64 => "Int64",
... is Type::Float32 { "Float32" }       Type::Float32 => "Float32",
... is Type::Ptr { "Ptr" }               Type::Ptr => "Ptr"
                                       }

Implementation

To avoid evaluation the "condition head" (common part) multiple times, it needs to be hoisted to a let-binding rather early in the process.
This has the benefit though that instead of some "magic" placeholder, we can refer to a "normal" let-binding during typechecking of the "condition tail" (branch-specific part).

dinfuehr / dora