Feature Request - Support if, switch, and select as Expressions

[YlguYtrid]

Summary
Currently, Dingo supports match as a first-class expression (excellent design!), but if, switch, and select remain statement-only constructs. This proposal requests extending expression semantics to these control structures to align with modern language patterns and improve composability.

Motivation

• Consistency: match is already an expression; extending this pattern to other control flows creates a cohesive mental model.
• Conciseness: Eliminates boilerplate temporary variables and multi-line assignments.
• Expressiveness: Enables direct use in assignments, function arguments, struct fields, and nested contexts.
• Modern Practice: Mirrors patterns in Rust (if/match expressions), Kotlin (when), Scala, Zig, and others where control flowis computation.

Current Limitation (Example)

// Verbose workaround required today
var status string
if x > 0 {
    status = "positive"
} else if x  0 { "positive" }
    else if x < 0 { "negative" }
    else { "zero" }
)

Additional Examples

switch as expression:
label := switch code {
case 200: "OK"
case 404: "Not Found"
default: "Unknown"
}

select as expression (channel context):

msg := select {
case v := <-ch1: format(v)
case v := <-ch2: sanitize(v)
default: "timeout"
}

Key Requirements

1. All branches must yield values of a consistent, inferable type (enforced at compile time).
2. Block bodies in branches should return the value of their final expression (like match).
3. Maintain existing statement semantics where expression context isn't used (backward compatible).
4. Clear error messages for type mismatches across branches.

Why This Matters

• Reduces cognitive load: users won’t need to remember which constructs are "expression-capable."
• Enables functional-style patterns critical for metaprogramming (e.g., generating config values inline during codegen).
• Strengthens Dingo’s position as a modern, ergonomic meta-language for Go ecosystems.

Optional Consideration
If full block support adds complexity initially, a minimal viable step could be:"Allow single-expression branches (no blocks) for if/switch/select in expression position, matching match's current capabilities."

[dingo-reviewer]

@YlguYtrid This is a solid feature direction, and you're right about the consistency angle.

Current state:

• match expressions work in all contexts (assignment, return, argument) — see examples/05_sum_types/match_contexts/
• Ternary (? :) is implemented for simple conditionals — see examples/09_ternary/
• features/ternary-operator.md already notes "implement both ternary AND if-expressions" as a decision

What's missing:

If/switch/select as expressions isn't designed yet. The ternary covers simple cases, but multi-branch if expressions (like Rust's) would fill a gap.

For your grade example, you'd currently use either chained ternary or match:

// Chained ternary (works today)
status := x > 0 ? "positive" : x < 0 ? "negative" : "zero"

// Or match (works today)
status := match true {
    x > 0 => "positive"
    x < 0 => "negative"
    _ => "zero"
}

The main value-add of if-expressions would be the familiar if/else if/else syntax in expression position. Worth designing properly.

Converting to discussion — this deserves community input on syntax and priority vs other roadmap items.