<p>A lot of C-family programming languages (C, C#, Java, etc.) require explicit line-ending characters in the form of semicolons. However, newer languages (Python, Kotlin) can infer the end of a line from the placement of newlines (although they often optionally allow semicolons as well). What are the advantages and disadvantages of using explicit line-ending characters versus inferring line-ends from newlines?</p>

<syntax>
What are the upsides of using explicit line-ending characters (like semicolons) as opposed to newlines?
CC BY-SA 4.0
2023-05-30T17:00:48.157Z
You mean the end of *statements* (or similar) not the end of lines I think. Lines can be continued.
Bruce Adams
<p>In my view, there aren't any extant advantages for using <em>compulsory</em> statement terminators (the blackletter kind of terminator, I mean, not whitespace like CRLF).</p>
<p>Many languages show that statement terminators are not necessary.</p>
<p>The main advantage of optional statement terminators is to allow more than one statement per line - not, as some others suggest, to ease the formatting of a single statement over multiple lines.</p>
<p>In some old languages like C, the syntax was also carefully designed in some respects to avoid verbosity and extravagance over the vertical axis of the screen. C was also designed to be highly economical with computer memory during its compilation. Those constraints no longer apply with anything like the intensity they applied in the 70s.</p>
<p>A language of modern design would almost always regard a statement as terminated by a newline alone, unless the content of the next line begins at an indentation in excess of the base indentation of that block.</p>

CC BY-SA 4.0
2023-07-08T16:42:36.347Z
2023-07-08T16:42:36.347Z
Steve
<h2>Disadvantages of requiring semicolons</h2>
<ul>
<li><p>It's common to want to edit text from some point up to the end of the line, to the point that Vim has a built-in keybinding for it (and other editors possibly too). In a language that requires semicolons, you will have to remember to re-add the semicolon.</p>
</li>
<li><p>Requiring line breaks is a form of preventing programmers from writing unreadable code. With semicolons, you're implicitly saying that you don't care about readability.</p>
</li>
<li><p>There is one less character you could possibly use for some other purpose.</p>
</li>
</ul>

CC BY-SA 4.0
2023-07-08T20:04:20.100Z
2023-07-08T20:04:20.100Z
xigoi
<h1>The semicolon can serve a purpose</h1>
<p>In addition to the excellent answers already provided, I'll point out that in many languages (specifically the ones used for scientific computing), lines ending in a semicolon will suppress printout, whereas lines without a semicolon may automatically print things to standard out. For example in MATLAB/Octave/Julia:</p>
<pre><code>A = 5;
B = 6;
C = 7
D = (8 + 9)*bsxfun(@times,A,B)
E = sqrt(5)*factorial(6)
F = (8 + 9)*bsxfun(@times,A,B);
G = sqrt(5)*factorial(6);
</code></pre>
<p>Prints out:</p>
<pre><code>C = 7
D = 510
E = 1610.0
</code></pre>
<p>Notice that <code>A</code> and <code>B</code> and <code>F</code> and <code>G</code> are all not printed, because of the semi-colons :)</p>

CC BY-SA 4.0
2023-05-16T21:16:46.073Z
2023-05-16T21:16:46.073Z
Nike Dattani
CC BY-SA 4.0
2023-05-30T16:59:06.600Z
Its not. The question is actually about *statement* endings not just newlines.
Bruce Adams
CC BY-SA 4.0
2023-05-30T17:27:23.033Z
LOL. It was only two minutes ***after*** your comment on my answer, that you wrote the following comment on the original question: "You mean the end of *statements* (or similar) not the end of lines I think. Lines can be continued." On one hand you "think" you know what the question was, and on the other hand you're telling me with supreme confidence what the question was.
Nike Dattani
CC BY-SA 4.0
2023-05-16T21:51:04.130Z
The purpose of semicolons and print-silencing seems irrelevant for a question about line-endings.
Brian BED
CC BY-SA 4.0
2023-05-16T21:55:02.813Z
My answer talks about line-ending with semicolons vs line-ending without semicolons, and what the difference in output would be with at least three different languages.
Nike Dattani
<p>In the first version of AEC (one that compiles to x86), I was using new-line as a statement terminator. Now I think that's not a good idea, so, in the second version of AEC (one that compiles to WebAssembly), I am using <code>;</code> for that.</p>
<p>Simply put, I think being able to break a long statement into multiple lines makes the code much more legible. Consider this statement from the x86 dialect of AEC:</p>
<pre><code>        If (distance &lt; (r + 0.5) ) | ( (y = 12) &amp; (x &gt; 40-1) &amp; (x &lt; 40 + (13 * 2) ) )
</code></pre>
<p>It would have been a lot more legible if you could break it into multiple lines, right?</p>
<p>You can read more about the differences between the two dialects of AEC on <a href="https://flatassembler.github.io/AEC_specification.html#DifferencesInDialects" rel="nofollow noreferrer">my blog</a>.</p>

CC BY-SA 4.0
2023-07-08T06:27:40.283Z
2023-07-08T17:29:51.830Z
2023-07-08T17:29:51.830Z
FlatAssembler
<p>Languages that use the end of line as the sentence separator need a special marker to use when the long sentence continues to the next line. Fortran uses continuation character at the position 6 (can be any, there are coding rules which one is more appropriate). Bash and Python uses reverse slash, <code>\</code>.</p>
<p>A language may have special rules when the  sentence continues to the next line without the marker, like in Python you can break within parenthesis.</p>
<p>The <strong>benefit</strong> of using new line as the statement boundary and then a continuation character if the statement spans over multiple lines may be that most of the sentences are short so <strong>continuation character is rare</strong>. Differently, if another symbol is used to separate the sentences, it must occur between any two sentences anyway.</p>
<p>The drawback of the new line marker that is placed at the end of the line is that if just spaces follow this marker, it suddenly &quot;does not work&quot; without obvious clue why. At least in Bash, a special attention must be paid there are no spaces after the <code>\</code>.</p>

CC BY-SA 4.0
2023-07-08T07:41:30.627Z
2023-07-19T16:41:10.053Z
2023-07-19T16:41:10.053Z
Audrius Meškauskas
<h1>No ambiguity with line wrapping expressions</h1>
<p>This is especially important in languages where the final expression is the return value. Is the following code:</p>
<pre><code>func foo() -&gt; Int {
  bar()
  - 5
}
</code></pre>
<p>expected to call <code>bar</code> and then return <code>-5</code>, or to return <code>bar() - 5</code>? If semicolons are required, the former would be:</p>
<pre><code>func foo() -&gt; Int {
  bar();
  - 5;
}
</code></pre>
<p>while the latter would be:</p>
<pre><code>func foo() -&gt; Int {
  bar()
  - 5;
}
</code></pre>
<p>Of course, I wouldn’t line wrap for such a short expression, but the point stands.</p>

CC BY-SA 4.0
2023-05-16T17:09:42.393Z
2023-05-16T17:09:42.393Z
Bbrk24
CC BY-SA 4.0
2023-07-02T16:17:50.337Z
I find it funny that FORTRAN marked continuations at the start of the following line, even though it would have been slightly cheaper to mark continuations on the previous line (allowing each line to be processed before reading the next line to ensure that it wasn't going to be continued), but other languages don't do that even though it would make continuations easier to see for programmers.
supercat
<h3>Disadvantages of using line ending characters</h3>
<ul>
<li>More visual noise. Every token less on the screen is one less that takes up valuable space in your brain</li>
</ul>
<h3>Disadvantages of not using line ending characters</h3>
<ul>
<li>Chaining operators needs parenthesis. This creates twice as much visual noise as semicolons would have.</li>
</ul>
<pre><code>let var = (a
           + b
           + c)
</code></pre>
<p>Instead of</p>
<pre><code>let var = a
          + b
          + c;
</code></pre>
<ul>
<li>Chaining functions needs the enclosing parenthesis on the new line:</li>
</ul>
<pre><code>a.b(
).c(
).d()
</code></pre>
<p>Instead of</p>
<pre><code>a.b()
 .c()
 .d()
</code></pre>
<ul>
<li>Dynamic insertion creates ambiguity (This one is Javascript specific, the rest should work in most languages)</li>
</ul>
<p>In Javascript</p>
<pre><code>return
&quot;b&quot;
</code></pre>
<p>is actually</p>
<pre><code>return;
&quot;b&quot;
</code></pre>
<p>thus this function will return undefined. This can be considered confusing behavior to those not used to it. Explicit line endings do not have this issue.</p>

CC BY-SA 4.0
2023-05-16T17:09:13.327Z
2023-07-11T16:04:33.957Z
2023-07-11T16:04:33.957Z
mousetail 'he-him'
CC BY-SA 4.0
2023-07-08T13:27:34.507Z
JavaScript is a weird language. Semicolons are almost always optional. The only time I've ever used one in my code is the very rare instance where a line began with "(" and I had to enter it as `;(`.
Ray Butterworth
CC BY-SA 4.0
2023-07-11T14:31:29.597Z
All the disadvantages listed here for not using semicolons are not applicable to F#. These may just be JavaScript quirks
James
CC BY-SA 4.0
2023-07-11T14:32:18.240Z
@Atog First 2 apply to python as well
mousetail 'he-him'
CC BY-SA 4.0
2023-07-11T16:03:41.230Z
I'd advise against JavaScript's approach.  Either consistently require newlines between statements (with some sort of continuation syntax for multi-line statements), or require semicolons between statements.  Allowing *either* and trying to guess what the programmer meant will cause trouble.
dan04
CC BY-SA 4.0
2023-07-20T19:58:13.147Z
Function and operator chaining work in JavaScript in exactly the way you say it can't. It can do this because an expression can't start with an infix operator, so a line that starts with an infix operator (like `+`) must be a continuation. Likewise, no independent identifiers can start with a `.`, so if a line starts with a `.`, it must be a continuation.
OpenAI was the last straw
CC BY-SA 4.0
2023-07-21T00:37:20.350Z
@James - Javascript's approach is very simplistic:  a statement ends on a newline if it is not a syntax error, or always on a semicolon.  You can certainly make more advanced schemes that are more intuitive to programmers, but they would usually involve some kind of lookahead which may make parsing slower, and parsing speed is important to javascript due to its intended application making it hard to cache preparsed scripts.
occipita
CC BY-SA 4.0
2023-05-16T17:10:42.593Z
I think you just ninja’d me and I didn’t even notice until I clicked “post”.
Bbrk24
CC BY-SA 4.0
2023-05-16T17:11:42.397Z
@Bbrk24 our answers are quite different though, they both have value
mousetail 'he-him'
CC BY-SA 4.0
2023-05-16T17:14:02.407Z
"Less visual noise" isn't among the "Disadvantages of using line ending characters", but rather among the advantages of omitting them.
Adám
<p>Statement <em>separators</em> (as opposed to terminators in C-style languages) are also common in functional languages when you want to run code for <a href="https://en.wikipedia.org/wiki/Side_effect_(computer_science)" rel="noreferrer">side effects</a>.</p>
<p>Take OCaml, for instance. It's very common to have your function body be a single expression, so you don't see the semicolon very often at all. If you need an <code>if</code> statement, that's still just one expression that happens to have inner parts.</p>
<pre><code>let rec factorial n =
    (* Look ma, no semicolons! *)
    if n = 0 then 1
    else n * factorial (n-1)
</code></pre>
<p>Likewise, local variables are introduced with <code>let ... in</code>, not with a separate variable declaration statement like in, for example, Javascript.</p>
<pre><code>let add_to n =
  let value = some_complicated_expression in
  n + value
</code></pre>
<p>The only time you explicitly <em>need</em> the semicolon is if you want to run an expression for side effects (discarding its values), then return something else. Haskell has a function called <code>traceId</code> that prints the given string and then returns it. We can write this in OCaml as follows.</p>
<pre><code>let trace_id x =
    print_endline x;
    x
</code></pre>
<p>We run <code>print_endline</code>, not because we care about its value, but because we want its side effects. Then we return something unrelated.</p>
<p>In a language like this in which sequencing multiple expressions is the exception rather than the norm, an argument could be made that the added complexity of auto-detected line endings is outweighed by the rarity of their use. So in a <a href="https://en.wikipedia.org/wiki/Functional_programming" rel="noreferrer">functional programming</a> language, simplicity of design is a huge benefit to explicit expression separators.</p>

CC BY-SA 4.0
2023-05-16T17:32:18.943Z
2023-05-17T03:45:47.050Z
2023-05-17T03:45:47.050Z
Silvio Mayolo
CC BY-SA 4.0
2023-07-20T20:07:39.273Z
Whereas the actual Haskell implementation of `traceId` works out to `traceId a = trace a a where trace string expr = unsafePerformIO $ do { traceIO string; return expr }; traceIO msg = withCString "%s\n" $ \cfmt -> do { let (nulls,msg') = partition (=='\0') msg; withCString msg' $ \cmsg -> debugBelch cfmt cmsg; when (not (null nulls)) $ withCString "WARNING: previous trace message had null bytes" $ \cmsg -> debugBelch cfmt cmsg }`. `debugBelch` is a foreign import, presumably implemented in C.
OpenAI was the last straw
<p>One pro is that explicit statement break syntax allows the programmer to avoid this tradeoff:</p>
<ul>
<li>I need to do extra work to allow a long statement to span multiple lines</li>
<li>It is not obvious whether a statement ends at the end of this line when I can't see the next line or when the rules are complex.</li>
</ul>
<p>And these cons can be mitigated with IDE plugin support:</p>
<ul>
<li>semicolons can be visually noisy especially when statements are short,
<br>but an IDE can style them in low-contrast to de-emphasize them.</li>
<li>semicolons require extra typing and conflict with muscle memory from languages like JavaScript where they're optional,
<br>but can be auto-inserted by an IDE</li>
</ul>
<p>For the first, consider</p>
<pre><code>let myString = &quot;Here's a line of text&quot;
             + &quot; and another line.&quot;
</code></pre>
<p>Maybe, since <code>+</code> can be a prefix and infix operator, you say that if the first token of the next line can be an infix operator, it continues.</p>
<p>But that causes problem when the program text seems to have a logical break.</p>
<pre><code>let x = f()

// A really long explanatory comment that
// is essential to understand but which also
// ensures that the last and next non-comment
// lines will never be on the screen at the
// same time.

(complexExpression).something()
</code></pre>
<p>You can solve the first problem by continuing expressions by default.   But that risks unintended merging in the second example.  The author probably did not expect <code>f()</code> to merge with <code>(complexExpression).something()</code> to parse like <code>(f()(complexExpression)).something()</code>, but that's a problem in Javascript because parentheses are not just for grouping; in infix position they're function application.</p>
<p>Maybe you can solve the logically breaking comment problem if your statement breaking decisions are sensitive to whitespace or comments, but probably at the risk of other potential surprises.</p>
<p>Explicit statement breaks lead to simple, easily explained rules as to where one statement ends and the next begins.</p>

CC BY-SA 4.0
2023-07-11T16:16:03.303Z
2023-07-11T21:42:15.230Z
2023-07-11T21:42:15.230Z
Mike Samuel
CC BY-SA 4.0
2023-10-19T16:24:13.733Z
I wonder whether it would be useful as an alternative to have a start-of-statement character?  This would make line conditions much more visually obvious, since a continuous vertical line of the same character would be have a gap in it, at the same time as it reduced visual noise since the characters for a section of code sharing the same level of indent would all aligned in a vertical stack.
supercat
CC BY-SA 4.0
2023-10-25T20:06:54.100Z
@supercat Analogously in natural language, [Discourse markers](https://en.wikipedia.org/wiki/Discourse_marker) are "include the particles oh, well, now, then, you know, and I mean".
Mike Samuel
CC BY-SA 4.0
2023-07-20T20:20:41.553Z
"...at the risk of other potential surprises." Such as the parsing behavior changing when a comment is deleted, for instance.
OpenAI was the last straw
# What are the upsides of using explicit line-ending characters (like semicolons) as opposed to newlines?
Posted by: username_0 on 2023-05-16
A lot of C-family programming languages (C, C#, Java, etc.) require explicit line-ending characters in the form of semicolons. However, newer languages (Python, Kotlin) can infer the end of a line from the placement of newlines (although they often optionally allow semicolons as well). What are the advantages and disadvantages of using explicit line-ending characters versus inferring line-ends from newlines?
**Tags:** syntax
> **Comments:**
> **username_1**: You mean the end of *statements* (or similar) not the end of lines I think. Lines can be continued.  
---
## 9 answers
### Answer by username_8 on 2023-05-16. Score: 26 | Accepted answer
No ambiguity with line wrapping expressions
This is especially important in languages where the final expression is the return value. Is the following code:
func foo() -> Int {
  bar()
  - 5
}

expected to call bar and then return -5, or to return bar() - 5? If semicolons are required, the former would be:
func foo() -> Int {
  bar();
  - 5;
}

while the latter would be:
func foo() -> Int {
  bar()
  - 5;
}

Of course, I wouldn’t line wrap for such a short expression, but the point stands.
> **Comments:**
> **username_9** (2023-07-02): I find it funny that FORTRAN marked continuations at the start of the following line, even though it would have been slightly cheaper to mark continuations on the previous line (allowing each line to be processed before reading the next line to ensure that it wasn't going to be continued), but other languages don't do that even though it would make continuations easier to see for programmers.  
---
### Answer by username_10 on 2023-05-16. Score: 13
Disadvantages of using line ending characters

More visual noise. Every token less on the screen is one less that takes up valuable space in your brain

Disadvantages of not using line ending characters

Chaining operators needs parenthesis. This creates twice as much visual noise as semicolons would have.

let var = (a
           + b
           + c)

Instead of
let var = a
          + b
          + c;


Chaining functions needs the enclosing parenthesis on the new line:

a.b(
).c(
).d()

Instead of
a.b()
 .c()
 .d()


Dynamic insertion creates ambiguity (This one is Javascript specific, the rest should work in most languages)

In Javascript
return
"b"

is actually
return;
"b"

thus this function will return undefined. This can be considered confusing behavior to those not used to it. Explicit line endings do not have this issue.
> **Comments:**
> **username_8** (2023-05-16): I think you just ninja’d me and I didn’t even notice until I clicked “post”.  
> **username_10** (2023-05-16): @Bbrk24 our answers are quite different though, they both have value  
> **username_16** (2023-05-16): "Less visual noise" isn't among the "Disadvantages of using line ending characters", but rather among the advantages of omitting them.  
> **username_11** (2023-07-08): JavaScript is a weird language. Semicolons are almost always optional. The only time I've ever used one in my code is the very rare instance where a line began with "(" and I had to enter it as `;(`.  
> **username_12** (2023-07-11): All the disadvantages listed here for not using semicolons are not applicable to F#. These may just be JavaScript quirks  
> **username_10** (2023-07-11): @Atog First 2 apply to python as well  
> **username_13** (2023-07-11): I'd advise against JavaScript's approach.  Either consistently require newlines between statements (with some sort of continuation syntax for multi-line statements), or require semicolons between statements.  Allowing *either* and trying to guess what the programmer meant will cause trouble.  
> **username_14** (2023-07-20): Function and operator chaining work in JavaScript in exactly the way you say it can't. It can do this because an expression can't start with an infix operator, so a line that starts with an infix operator (like `+`) must be a continuation. Likewise, no independent identifiers can start with a `.`, so if a line starts with a `.`, it must be a continuation.  
> **username_15** (2023-07-21): @James - Javascript's approach is very simplistic:  a statement ends on a newline if it is not a syntax error, or always on a semicolon.  You can certainly make more advanced schemes that are more intuitive to programmers, but they would usually involve some kind of lookahead which may make parsing slower, and parsing speed is important to javascript due to its intended application making it hard to cache preparsed scripts.  
---
### Answer by username_17 on 2023-05-16. Score: 9
Statement separators (as opposed to terminators in C-style languages) are also common in functional languages when you want to run code for side effects.
Take OCaml, for instance. It's very common to have your function body be a single expression, so you don't see the semicolon very often at all. If you need an if statement, that's still just one expression that happens to have inner parts.
let rec factorial n =
    (* Look ma, no semicolons! *)
    if n = 0 then 1
    else n * factorial (n-1)

Likewise, local variables are introduced with let ... in, not with a separate variable declaration statement like in, for example, Javascript.
let add_to n =
  let value = some_complicated_expression in
  n + value

The only time you explicitly need the semicolon is if you want to run an expression for side effects (discarding its values), then return something else. Haskell has a function called traceId that prints the given string and then returns it. We can write this in OCaml as follows.
let trace_id x =
    print_endline x;
    x

We run print_endline, not because we care about its value, but because we want its side effects. Then we return something unrelated.
In a language like this in which sequencing multiple expressions is the exception rather than the norm, an argument could be made that the added complexity of auto-detected line endings is outweighed by the rarity of their use. So in a functional programming language, simplicity of design is a huge benefit to explicit expression separators.
> **Comments:**
> **username_14** (2023-07-20): Whereas the actual Haskell implementation of `traceId` works out to `traceId a = trace a a where trace string expr = unsafePerformIO $ do { traceIO string; return expr }; traceIO msg = withCString "%s\n" $ \cfmt -> do { let (nulls,msg') = partition (=='\0') msg; withCString msg' $ \cmsg -> debugBelch cfmt cmsg; when (not (null nulls)) $ withCString "WARNING: previous trace message had null bytes" $ \cmsg -> debugBelch cfmt cmsg }`. `debugBelch` is a foreign import, presumably implemented in C.  
---
### Answer by username_18 on 2023-07-11. Score: 4
One pro is that explicit statement break syntax allows the programmer to avoid this tradeoff:

I need to do extra work to allow a long statement to span multiple lines
It is not obvious whether a statement ends at the end of this line when I can't see the next line or when the rules are complex.

And these cons can be mitigated with IDE plugin support:

semicolons can be visually noisy especially when statements are short,
but an IDE can style them in low-contrast to de-emphasize them.
semicolons require extra typing and conflict with muscle memory from languages like JavaScript where they're optional,
but can be auto-inserted by an IDE

For the first, consider
let myString = "Here's a line of text"
             + " and another line."

Maybe, since + can be a prefix and infix operator, you say that if the first token of the next line can be an infix operator, it continues.
But that causes problem when the program text seems to have a logical break.
let x = f()

// A really long explanatory comment that
// is essential to understand but which also
// ensures that the last and next non-comment
// lines will never be on the screen at the
// same time.

(complexExpression).something()

You can solve the first problem by continuing expressions by default.   But that risks unintended merging in the second example.  The author probably did not expect f() to merge with (complexExpression).something() to parse like (f()(complexExpression)).something(), but that's a problem in Javascript because parentheses are not just for grouping; in infix position they're function application.
Maybe you can solve the logically breaking comment problem if your statement breaking decisions are sensitive to whitespace or comments, but probably at the risk of other potential surprises.
Explicit statement breaks lead to simple, easily explained rules as to where one statement ends and the next begins.
> **Comments:**
> **username_14** (2023-07-20): "...at the risk of other potential surprises." Such as the parsing behavior changing when a comment is deleted, for instance.  
> **username_9** (2023-10-19): I wonder whether it would be useful as an alternative to have a start-of-statement character?  This would make line conditions much more visually obvious, since a continuous vertical line of the same character would be have a gap in it, at the same time as it reduced visual noise since the characters for a section of code sharing the same level of indent would all aligned in a vertical stack.  
> **username_18** (2023-10-25): @supercat Analogously in natural language, [Discourse markers](https://en.wikipedia.org/wiki/Discourse_marker) are "include the particles oh, well, now, then, you know, and I mean".  
---
### Answer by username_2 on 2023-07-08. Score: 3
In my view, there aren't any extant advantages for using *compulsory* statement terminators (the blackletter kind of terminator, I mean, not whitespace like CRLF).

Many languages show that statement terminators are not necessary.

The main advantage of optional statement terminators is to allow more than one statement per line - not, as some others suggest, to ease the formatting of a single statement over multiple lines.

In some old languages like C, the syntax was also carefully designed in some respects to avoid verbosity and extravagance over the vertical axis of the screen. C was also designed to be highly economical with computer memory during its compilation. Those constraints no longer apply with anything like the intensity they applied in the 70s.

A language of modern design would almost always regard a statement as terminated by a newline alone, unless the content of the next line begins at an indentation in excess of the base indentation of that block.
---
### Answer by username_7 on 2023-07-08. Score: 3
Languages that use the end of line as the sentence separator need a special marker to use when the long sentence continues to the next line. Fortran uses continuation character at the position 6 (can be any, there are coding rules which one is more appropriate). Bash and Python uses reverse slash, `\`.

A language may have special rules when the sentence continues to the next line without the marker, like in Python you can break within parenthesis.

The **benefit** of using new line as the statement boundary and then a continuation character if the statement spans over multiple lines may be that most of the sentences are short so **continuation character is rare**. Differently, if another symbol is used to separate the sentences, it must occur between any two sentences anyway.

The drawback of the new line marker that is placed at the end of the line is that if just spaces follow this marker, it suddenly "does not work" without obvious clue why. At least in Bash, a special attention must be paid there are no spaces after the `\`.
---
### Answer by username_3 on 2023-07-08. Score: 2
## Disadvantages of requiring semicolons

* It's common to want to edit text from some point up to the end of the line, to the point that Vim has a built-in keybinding for it (and other editors possibly too). In a language that requires semicolons, you will have to remember to re-add the semicolon.
* Requiring line breaks is a form of preventing programmers from writing unreadable code. With semicolons, you're implicitly saying that you don't care about readability.
* There is one less character you could possibly use for some other purpose.
---
### Answer by username_4 on 2023-05-16. Score: 1
The semicolon can serve a purpose
In addition to the excellent answers already provided, I'll point out that in many languages (specifically the ones used for scientific computing), lines ending in a semicolon will suppress printout, whereas lines without a semicolon may automatically print things to standard out. For example in MATLAB/Octave/Julia:
A = 5;
B = 6;
C = 7
D = (8 + 9)*bsxfun(@times,A,B)
E = sqrt(5)*factorial(6)
F = (8 + 9)*bsxfun(@times,A,B);
G = sqrt(5)*factorial(6);

Prints out:
C = 7
D = 510
E = 1610.0

Notice that A and B and F and G are all not printed, because of the semi-colons :)
> **Comments:**
> **username_5** (2023-05-16): The purpose of semicolons and print-silencing seems irrelevant for a question about line-endings.  
> **username_4** (2023-05-16): My answer talks about line-ending with semicolons vs line-ending without semicolons, and what the difference in output would be with at least three different languages.  
> **username_1** (2023-05-30): Its not. The question is actually about *statement* endings not just newlines.  
> **username_4** (2023-05-30): LOL. It was only two minutes ***after*** your comment on my answer, that you wrote the following comment on the original question: "You mean the end of *statements* (or similar) not the end of lines I think. Lines can be continued." On one hand you "think" you know what the question was, and on the other hand you're telling me with supreme confidence what the question was.  
---
### Answer by username_6 on 2023-07-08. Score: 1
In the first version of AEC (one that compiles to x86), I was using new-line as a statement terminator. Now I think that's not a good idea, so, in the second version of AEC (one that compiles to WebAssembly), I am using ; for that.
Simply put, I think being able to break a long statement into multiple lines makes the code much more legible. Consider this statement from the x86 dialect of AEC:
        If (distance < (r + 0.5) ) | ( (y = 12) & (x > 40-1) & (x < 40 + (13 * 2) ) )

It would have been a lot more legible if you could break it into multiple lines, right?
You can read more about the differences between the two dialects of AEC on my blog.
---
