Remove indented-else syntax? · compiler development

Stream: compiler development

Topic: Remove indented-else syntax?

Joshua Warner (Jan 21 2025 at 02:54):

I've been seeing quite a few fuzzing bugs with indented else; perhaps it's time to remove that?

For reference, that's when you do something like this:

x = |args|
    if a == 0 then
        foo
        else
    this_is_part_of_the_else!()
    so_is_this!()

Technically speaking, I'm not sure the intended replacement (early-return) is ready - but it's also easy to migrate away from this automatically with the formatter.

What this would look like:

Change the formatter such that it turns any indented else's back into "normal" else's (which will lead to some rightward drift)
Some time later, after everyone's had a chance to upgrade, remove the ability to parse indented-else syntax

Thoughts?

Luke Boswell (Jan 21 2025 at 02:58):

If it's on another line, shouldn't it be indented from the else?

I guess I don't really understand or have any experience with early return

Joshua Warner (Jan 21 2025 at 02:59):

It was introduced here: #ideas > "early returns" via formatter

Luke Boswell (Jan 21 2025 at 02:59):

Also see #ideas > early return statement @ 💬

Joshua Warner (Jan 21 2025 at 03:01):

The idea is/was that we can remove "rightward drift" of if statements, if we allow the else branch to be indented at the level of the outer scope - and that this is a simple syntactic transformation.

Joshua Warner (Jan 21 2025 at 03:01):

My understanding is that the intent is to replace that with early return statements

Joshua Warner (Jan 21 2025 at 03:02):

I have ideas on how to fix the bugs fuzzing is finding with this syntax, but doesn't seem worth implementing if we're just going to rip it out soon anyway

Luke Boswell (Jan 21 2025 at 03:02):

This makes sense to me #ideas > "early returns" via formatter @ 💬

I find the hanging else really confusing

Luke Boswell (Jan 21 2025 at 03:02):

processArgs = \args =>
    if List.isEmpty args then
        return Err NoArgs

    # rest of body

Joshua Warner (Jan 21 2025 at 03:02):

Yeah, I much prefer early return as well

Joshua Warner (Jan 21 2025 at 03:03):

I'm going to throw together a PR to remove it, but let's not merge until we get the final go-ahead :smiley:

Joshua Warner (Jan 21 2025 at 03:04):

(by "remove it", I just mean step (1), above)

Joshua Warner (Jan 21 2025 at 03:04):

Shouldn't be a breaking change at all

Joshua Warner (Jan 21 2025 at 03:19):

https://github.com/roc-lang/roc/pull/7536

Sam Mohr (Jan 21 2025 at 03:32):

I vote just remove it

Sam Mohr (Jan 21 2025 at 03:33):

And then implement else-less ifs

Sam Mohr (Jan 21 2025 at 03:33):

No one is using it

Sam Mohr (Jan 21 2025 at 03:33):

It was a stop gap that isn't useful on its own now that we have return

Joshua Warner (Jan 21 2025 at 04:05):

Anyone object?

Richard Feldman (Jan 21 2025 at 04:52):

yeah let's axe it :rip:

Richard Feldman (Jan 21 2025 at 04:58):

honestly this was one of the experiments that motivated adding return in the first place

Richard Feldman (Jan 21 2025 at 04:59):

it revealed that the answer to the question "can we get a comparably nice experience with formatting instead of a new keyword?" was "no"

Sam Mohr (Jan 21 2025 at 04:59):

And now error handling is way better because of return!

Anthony Bullard (Jan 21 2025 at 14:09):

I'm fine with this (I didn't even realize this was allowed in the first place), good riddance!

Last updated: Jul 06 2025 at 12:14 UTC