Stream: ideas

Topic: `when-is-then-is-then-...` notation

Simon Taeter (Mar 02 2025 at 09:42):

Hello! I'm still a beginner here but I have been reading quite a bit about the different design tradeoffs you folks are doing. I come from Elm, I see the issues Roc aims to solve and I love the way you do so :)

I believe there is a bit of an issue around the when operator. Here is a pattern that might be of interest :

when my_pattern
is OptionA a then
    do_something a
is OptionB maybe_b then
    when maybe_b
    is Just b then
        do_something_else b
    is Nothing then
        do_a_barrel_roll
is OptionC c then
    if i_dont_like c then
        la_reponse_d
    else
        c
is _ then
    handle_this_general_case

Pros :

• very readable and explicit
• removes one indentation layer (much better for nesting)
• matches the if-then-else structure
• avoids the -> and =>
• no need for nesting brackets

Cons :

• bit more verbose
• other things I'm not thinking about...

Notification Bot (Mar 02 2025 at 09:44):

This topic was moved here from #ideas > when-is..-then notation by Simon Taeter.

Sam Mohr (Mar 02 2025 at 09:56):

We've actually had quite a bit of discussion recently around trying to make Roc not have whitespace significance because of how much some people hate languages that have it. This has mainly culminated in #ideas > braces syntax where we agreed that using { and } was generally liked by everyone in that discussion, even those that prefer whitespace-based languages

Sam Mohr (Mar 02 2025 at 09:57):

Two consequences of that move to a brace-delimited language:

• if a then b else c -> if a { b } else { c }
• when a is b -> c -> match a { b -> c }

Sam Mohr (Mar 02 2025 at 09:57):

So we're actually moving to a match keyword over "when-is" because it matches the new if syntax better

Sam Mohr (Mar 02 2025 at 09:58):

We could discuss moving back to "when-is", but we'd probably need to figure out how to support "if-then-else" with keywords instead of braces first

Sam Mohr (Mar 02 2025 at 09:59):

The benefit of braces is that they are much easier for humans and computers alike to parse, when the whitespace is not already correct, and that would probably be a hard barrier to overcome with a proposal to move back to "if-then-else"

Simon Taeter (Mar 02 2025 at 10:04):

Yes I wrote there too

Simon Taeter (Mar 02 2025 at 10:07):

Though you could also adapt it to use brackets :

when my_pattern
is OptionA a {
    do_something a
}
is OptionB maybe_b {
    when maybe_b
    is Just b {
        do_something_else b
    }
    is Nothing {
        do_a_barrel_roll
    }
}
is OptionC c {
    if i_dont_like c {
        la_reponse_d
    }
    else {
        c
    }
}
is _ {
    handle_this_general_case
}

Last updated: Jun 16 2026 at 16:19 UTC