Semicolon?

[GheorgheMorari]

Why do we need semicolons?

[Antonioescp]

I've used C++ and kotlin enough to notice how not needing semicolon improves readability

[diceptia]

Semicolon waste of time

[josh11b]

My recollection of the reasoning behind required semicolons is:

• matches C/C++
• makes it easier for tools to parse and operate on source code
• readability is more important to us than writability

That being said, we do want it to be as easy as possible to determine if a ; is missing for error detection and recovery and so things like IDEs can help put them into the code for you. That mostly impacts the rest of the grammar, though.

Incidentally, automatic semicolons are a stronger restriction on the rest of the grammar.

I would also like to note that the rules for automatic semicolon insertion end up complicated, and very different for different languages. We have a strong preference for simple rules, particularly at first. If something is shown to be a real problem in practice, we can always add complexity later.

Comments saying "I like X" or "I don't like X" don't really contribute to the conversation. Much more helpful would be a reason for or against X that hasn't already been considered.

[scarf005]

readability is more important to us than writability

it may depend on people. for example, I disagree with semicolons because to me they are visual clutter and harms both readability and writability.

[chandlerc]

Just want to highlight that the issue-for-leads on this topic was decided specifically agreeing with the rationale written up here: #1924 (comment)

[OliverStoll]

I do completely agree with @scarf005 here, I think semicolons do not help readability at all but rather hurt it.

[janpfeifer]

My understanding is that semicolons were created to simplify the parsers and tools for languages (c, pascal, etc), not to improve human readability. Notice languages that got rid of it (Python, Go, etc) I've never heard anyone asking for ";" back to improve readability.

I don't think the argument that semicolons are more readable stands.

[SamuelTrew]

From a writability abd readability point of view, as long as having them doesn't impact the future design decisions to allow/not allow things like inlining and if statement then I'm personally fine either way.

Trouble comes when it limits (or at least makes much less readable) future design decisions so as to have to get around having or not having them.

Feels like something that could be decided much later on in the process once more formal specs have been decided for the rest of the language

[flysand7]

Reasoning from the first principles, I can bring something to the table in favor of mandatory semicolons with references to the design principles

First, we need to be specific about the alternatives to mandatory-semicolons, and I can think of two alternatives:

1. Semicolons are optional

This approach is used by most popular imperative languages, i.e. JavaScript, Python, Go. These languages use Automatic Semicolon Insertion (ASI) or treat newlines at certain points as semicolons.

One thing to understand about ASI is that it's not perfect substitute for semicolons. There exist edge cases where syntax is ambiguous to a human eye. For example

return
  ++x  // Is this a continuation of the previous statement or is it another statement?

On the question of whether programmers who care about maintainability would format their code like that, probably not, but some formatters include a feature of splitting a long line into several lines if it exceedes a certain limit. It wouldn't be nice if your formatting tools messed up the way your code works. Also from time to time everyone writes long lines of code, making this behaviour someting to be afraid of violates these design principles:

Adhere to the principle of least surprise

Ordinary tasks should not require extraordinary care, because humans cannot consistently avoid making mistakes for an extended amount of time.

Support tooling at every layer of the development experience, including IDEs. The design and implementation of Carbon should make it easy to create such tools and make them effective. Carbon should avoid syntax and textual structures that are difficult to recognize and mechanically change without losing meaning.

Furthermore since optional semicolons make certain syntax ambiguous the following design principle is violated:

Syntax should be easily parsed and scanned by any human in any development environment, not just a machine or a human aided by semantic hints from an IDE.

In the grand scheme of things ASI being unreliable is not much of an issue. Because, if you consider a tiny snippet of code above, there are other compiler warnings that could catch these spurious lines, for example "Having extra statements after return" or "Expression without side effects result of which isn't being used". A much more pressing issue is that the places where ASI happens are strictly defined and should support breaking statements into several lines. If a new syntactic construction is added into Carbon, the places where ASI happens should be revisited and the new "ASI breakpoints" need to be added (Currently not seeing any issues with that). Furthermore, even if developers add those breakpoints in certain places it still limits the syntactic freedom of people writing in that langauge.

Which might be violating:

Focus on encouraging appropriate usage of features rather than restricting misuse

2. Semicolons aren't allowed

This is another option for no-semicolons. If you know of any examples of imperative statement-based programming languages that do this feel free to reply. Due to lack of examples there isn't anything I know for certain about this approach so maybe it's the one worth discussing.

I'm assuming that this would require treating newline as a token, and treating this token similarly to semicolon. The care still needs to be taken about where newlines terminates a statement and where it simply extends it to a new line. This also makes it more complicated to implement formatters that involve inserting newlines to keep lines short.

Depending on how it's implemented the no-semicolon approach might be violating:

Adhere to the principle of least surprise

Focus on encouraging appropriate usage of features rather than restricting misuse

Support tooling at every layer of the development experience, including IDEs. The design and implementation of Carbon should make it easy to create such tools and make them effective. Carbon should avoid syntax and textual structures that are difficult to recognize and mechanically change without losing meaning.

Which is an unfair thing to say, but unless there's a proposal for no-semicolons approach that would detail its semantics and reasoning, I don't think there's much to discuss.

---

The ultimate tradeoff is whether convenience of not having to write semicolons when you don't have to is worth complicating tools by defining complex rules for statement parsing. For now I won't make any judgement of what's better, since I'm curious what the community has to say.

[scarf005]

2: treating newline as a token, and treating this token similarly to semicolon.
If you know of any examples of imperative statement-based programming languages that do this feel free to reply.

kotlin, swift, and python (semicolon is statement separator, not terminator, so it belongs in category 2) uses newline as statement terminators.

some formatters include a feature of splitting a long line into several lines if it exceedes a certain limit. It wouldn't be nice if your formatting tools messed up the way your code works.

i couldn't find about if carbon has specific use cases for ( ), but they are used for splitting long lines in python, kotlin, and swift. carbon could use them too.

my opinion about long line of code is that

• like in python, \ could be used to ignore line breaks (sort of anti-terminator)
• most of time there would be more short lines than long lines in code, so introducing ; for the sake of long lines might not be the best idea.

return
++x // Is this a continuation of the previous statement or is it another statement?

using newlines as statement terminator would disambiguate situations like this. then they are return; and ++x;

The ultimate tradeoff is whether convenience of not having to write semicolons when you don't have to is worth complicating tools by defining complex rules for statement parsing.

i'm also curious of the extra complexity from usage of optional semicolons, but here are a bit of grammar for function declaration in kotlin: (NL is newline)

functionDeclaration
    : modifiers?
      FUN (NL* typeParameters)? (NL* receiverType NL* DOT)? NL* simpleIdentifier
      NL* functionValueParameters
      (NL* COLON NL* type)?
      (NL* typeConstraints)?
      (NL* functionBody)?
    ;

[flysand7]

Thank you for the reply, you brought up some good points.

Using parentheses to allow multiple lines seems like a good alternative for splitting a long expression into multiple lines in case of no-semicolon approach. I imagine the way it works is by ignoring newlines within expressions, but in statements they behave as if semicolon, so no special handling is required.

The point about complexity isn't that it is intrinsically complex, but that the syntax definitions become longer because all those places where a newline can be inserted have to be marked, which results in the parser code being larger (because of all those cases where it needs to eat the newlines), thus adding extra branches. I would estimate the performance impact to be relatively small (most of the time in compilers typically comes from type checking and code generation, not parsing), but real measurements would need to be taken in order to draw conclusions.

Introducing physical line continuations (\ at the end of the line in C and python) may be an unnecessary complication for lexers though, since parens would provide a good simple way of extending expressions (Although I'm not sure whether parens cover most cases people care about, maybe there are some non-expressions that can have ambiguous syntax?).

The way kotlin does function declaration is interesting, unlike Go and Odin they allow newlines in more places, and they allow multiple consecutive newlines in those places. It's a more unrestrictive syntax than the optional-newline languages.

[Dietr1ch]

return
  ++x  // Is this a continuation of the previous statement or is it another statement?

This is a bad example IMO. Getting rid of the semicolons comes in hand with the expectation that expressions are terminated on the same line unless there's still unmatched parentheses.

Without semicolons, it should be either,

• A simple, single line expression,

  return ++x

• A multi-line expression with well defined ending

  return (
    ++x       /// If your buffer ends here, there's still no doubt that this expression goes on
    + y)

[YagaoDirac]

I think because carbon means not to utilize any modern IDE feature, it means to only use text based design, so ; should be very helpful.
Modern IDE can help add ;, but this violets the assumptions.

[flysand7]

It's not about IDE support, since inserting semicolons is done at the compiler level, not an IDE level

[WilliamYe79]

I guess the reason Carbon chooses to add ";" as the statement terminator to be consistant with C++.
Yes, as many of you guys said: "Go/Python/Kotlin all use new line as their statement terminator". However, C/C++/Java/C#/Rust/Zig all chose to use ";" as their statement terminator. So, I believe it is really just a personal preference.
As a Java developer, it is quite usual for me to break one statement into multiple lines (often over 5 lines) to make it easier to read. If I add "\" at the end of all the broken lines, it will also be a lot of typing :-P