ambiguity with implicit returns and implicit semicolons

[thejoshwolfe]

The combination of implicit semicolons after certain statements and the implicit return at the end of a block (e.g. a function body) causes ambiguity.

Currently these are all equivalent:

fn abs(x: f32) -> f32 {
    if (x < 0.0) {
        return -x;
    } else {
        return x;
    }
}
fn abs(x: f32) -> f32 {
    return if (x < 0.0 {
        -x
    } else {
        x
    };
}
fn abs(x: f32) -> f32 {
    if (x < 0.0) {
        -x
    } else {
        x
    }
}
fn abs(x: f32) -> f32 {
    return if (x < 0.0) -x else x;
}
fn abs(x: f32) -> f32 {
    if (x < 0.0) -x else x
}

However, this is problematic because of the ambiguity that comes from an implicit semicolon after some statement-level constructs.

fn main() {
    if (a) {
        foo();
    } else {
        bar();
    } // no semicolon needed here
    if (b) {
        bar();
    } // or here
}

The implicit semicolon is valuable because C has so thoroughly conditioned us to expect compound statements that use {} to end at the }. But where does the implicit semicolon really go? What about these examples:

fn main() {
    if (a) { foo() } else { bar() }
    if (b) { bar() }
    if (a) foo() else bar()
    if (b) bar()

    if (a) foo else bar
    (); // does this call bar()?
    if (b) bar
    {} // does this struct-initialize bar{}?

    ( bar )();
    { bar }(); // what does this mean?
    if (b) { bar }(); // what does this mean?

    // this should probably be a syntax error, but it currently isn't:
    comptime 1 1;
}

Proposal:

When one of the following "compound statement"-like constructs appears at block scope, it can optionally qualify for an implicit semicolon if it uses {} around its "body"-like component (details below):

• switch: already always uses {}, so always qualifies for implicit semicolon.
• {...}: a nested block at block scope always qualifies for implicit semicolon.
• while, for: putting {} around the body qualifies for implicit semicolon.
• comptime: putting {} around the expression qualifies for implicit semicolon.
• if, try: putting {} around the "else" body, if any, otherwise around the "then" body qualifies for implicit semicolon.

If a statement qualifies for an implicit semicolon, the statement ends at the } and cannot be its containing-block's return expression. In other words, the implicit semicolon is always effectively present, not optionally present if necessary.

Here are some examples of this proposal in action:

fn abs(x: f32) -> f32 {
    // no {}, so no implicit semicolon, so this is the return expression:
    if (x < 0.0) -x else x
}
fn abs(x: f32) -> f32 {
    // this `if` is not at statement level, so these {} don't earn any implicit semicolons:
    return if (x < 0.0) {
        -x
    } else {
        x
    };
}
fn abs(x: f32) -> f32 {
    // this statement gets a semicolon, and so does nothing
    if (x < 0.0) {
        -x
    } else {
        x
    }
    // error for not returning an f22
}
fn main() {
    { bar }(); // syntax error for empty `()`
    { bar };(); // equivalent to the above
    if (b) { bar }(); // syntax error for empty `()`
    if (b) { bar };(); // equivalent to the above

    comptime 1 1; // syntax error
    comptime {1} 1; // ok
}
fn getKindName(kind: Kind) -> []const u8 {
    // need the return here because switch uses {}
    return switch (kind) {
        KindA => "A",
        KindB => "B",
    };
}

A separate idea to consider is to require that the "then" and "else" bodies if if and try agree on use of {}. That would simplify this proposal slightly, but is really a separate idea.

[andrewrk]

what if you want to use a switch expression as the result of a block?

const value = if (a) {
    b
} else {
    switch (c) {
        KindA => "A",
        KindB => "B",
    }
};

[thejoshwolfe]

Here's a simplification to the syntax. For each language construct in the above comment that can optionally qualify for semicolon insertion, we say that its body is a special syntactic element called BodyBlockOrExpression.

BodyBlockOrExpression : Block | Expression

Now the grammar will first check for a block without allowing any suffix operators on it, but if the first token isn't {, then the body can be any expression. This ensures that there are no suffix operators on the expression if it is a block.

[thejoshwolfe]

alright new (old) plan, what I just proposed with BodyBlockOrExpression is already status quo, because of this grammar definition:

Expression : BlockExpression | NonBlockExpression

Every time we expect an expression, we first check for a BlockExpression, and if that works, we stop without considering any suffix operators. This means you can't do this:

const x = {1} + {2};

Because the first } ends the whole expression. Is this intentional? I mean, it solves the ambiguity nicely, but I was a bit surprised to find this out.

[andrewrk]

Is this intentional?

Yeah I think so. And then you can always put parentheses around it to make it work.

[thejoshwolfe]

Take this example code, which parses fine at first:

fn getGravityBetween(a: &Entity, b: &Entity) -> f32 {
    return gravity_constant * {
        const a_mass = a.getMass();
        printf("a mass: {}\n", a_mass);
        a_mass
    } * {
        const b_mass = b.getMass();
        printf("b mass: {}\n", b_mass);
        b_mass
    } / {
        const distance = getDistance(a, b);
        distance * distance
    };
}

Now I'll simplify the important statement to this, so that it's easier to see the changes I'm making to it:

fn getGravityBetween(a: &Entity, b: &Entity) -> f32 {
    const distance = getDistance(a, b);
    return gravity_constant * { a.getMass() } * { b.getMass() } / { distance * distance };
}

Watch what happens when you add some parentheses:

return gravity_constant * ({ a.getMass() } * { b.getMass() } / { distance * distance });
//                        (                ^                                          )
// error: expected token ')', found '*'

return (gravity_constant * { a.getMass() } * { b.getMass() } / { distance * distance });
//     (                                                                              )
// fine

return gravity_constant * ({ a.getMass() } * { b.getMass() }) / { distance * distance };
//                        (                ^                )
// error: expected token ')', found '*'

return(gravity_constant * ({ a.getMass() }) * { b.getMass() } / { distance * distance };
//                        (               )
// fine

Is this really intentional?

I understand the grammar enough to know exactly why all of this is happening, but I don't like it. I think this is very confusing.

[andrewrk]

I agree this is a serious problem, although I'm surprised that I've never run into this issue in practice. I also don't have any proposals (yet) to fix it.

[thejoshwolfe]

After the above commit, all the gravity example expressions parse fine.

Additionally, whenever there's an implicit semicolon, you can't have a suffix operator reach through it. So the following doesn't work:

if (a) { b }(); // doesn't call b(), because there's an implicit semicolon after the `}`.

what if you want to use a switch expression as the result of a block?

const value = if (a) {
    b
} else {
    switch (c) {
        KindA => "A",
        KindB => "B",
    }
};

For now, an implicit semicolon does not disqualify the statement from being a block's result expression, so the above still works.

[thejoshwolfe]

Oh i forgot to mention: this commit also makes implicit semicolons only possible after }, as discussed above. That's important.

[thejoshwolfe]

While writing a test for #297, I noticed a problem with my implementation here.

comptime { foo() } // implicit semicolon
comptime foo(); // need explicit semicolon
comptime (foo()); // need explicit semicolon
comptime ({ foo() }) // should need explicit semicolon, but doesn't