Semicolons terminate statements

[jonmeow]

Statements, declarations, and definitions will terminate with either a semicolon
(;) or a close curly brace (}). Semicolons are never optional.

For example, with a semicolon, x = x + 2;. With a close curly brace,
for ( ... ) { ... }, or class C { ...}.

This does not affect any approved proposal; rather, it makes an important
assumption explicit.

Based on lead decision #1924

Fixes #2002

[zygoloid]

I think the rule as written is too strong, and that the rule we want is that statements are terminated by either a semicolon or a close brace. Specifically, I don't think we want to require semicolons after for, if, or match statements (which are all terminated by close braces), nor after declaration statements that define classes and similar with a braced body (which you already point out as an exception).

I wonder if it's also worth adding something along these lines to principles/, about only using tokens and not whitespace to determine how to parse, but probably not as part of this proposal -- keeping this narrow and focused seems like the best way to make progress.

[jonmeow]

I think the rule as written is too strong, and that the rule we want is that statements are terminated by either a semicolon or a close brace. Specifically, I don't think we want to require semicolons after for, if, or match statements (which are all terminated by close braces), nor after declaration statements that define classes and similar with a braced body (which you already point out as an exception).

Adjusted phrasing. Note now I've trimmed the abstract slightly, and shifted more to the "proposal" section (still thin, because I don't think there's that much to say).

I wonder if it's also worth adding something along these lines to principles/, about only using tokens and not whitespace to determine how to parse, but probably not as part of this proposal -- keeping this narrow and focused seems like the best way to make progress.

I think https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/principles/low_context_sensitivity.md may already address this sufficiently, or put differently, maybe we could adjust that principle rather than adding another if you want it more explicitly addressed. The examples in the principle are more syntactic, but "visual aids" still has a section there and there's the up-front comment "It can be subtle: the contextual clues might be easily missed or mistaken." which could be inferred to apply to whitespace.

[zygoloid]

Generally looks good to me.

I think it'd be nice to have a slightly stronger case made for the various "optional semicolons" rules having problems and surprises, but non-essential. Comments here are generally suggesting things you could say to make that case more strongly, none seems essential to address.

[zygoloid]

Thanks, this looks good to me, asking other leads...

[chandlerc]

LG, thanks for writing it all up!