Remove the need for semicolons

[lunaticLipid]

I don't understand the usefulness of semicolons other than making the compiler simpler to write, why can't we do away with them?

[marler8997]

I've seen this discussed a few times in the D language, here's some links:

http://forum.dlang.org/post/[email protected]

http://forum.dlang.org/post/[email protected]

There's been quite a few posts on the D forums about this, but the general consensus there seemed to be that it was not an win overall.

[thejoshwolfe]

semicolons are necessary for Zig's grammar. for example:

• a; {} vs a{}
• a; [1]u8 vs a[1]u8

[raulgrell]

The only reasonable way to remove semicolons is to make newlines essentially behave like a statement terminator (effectively an implicit semicolon). This starts to feel like Javascript's automatic semicolon insertion.

The only conflict with existing grammar is the implicit return when the semicolon is omitted. We would have to require somehting like the return :block syntax proposed in #346. While I at first did not like the implicit block-return syntax I have found it a joy to use.

Then comes the issue of chaining calls:

const x = longVariableName.longFunctionName(lots, of, parameters).anotherCall(with, stuff);
// vs
const x = longVariableName
        .longFunctionName(lots, of, parameters)
        .anotherCall(with, stuff);

I also like the visual cues provided by semicolons

• The semicolon communicates a statement as opposed to an expression
• Multiple statements in one line can sometimes improve readability.
• One statement in multiple lines can sometimes improve readability.
• Number of semicolons says more about code than number of lines

[PavelVozenilek]

I remember that old discussion in D language forum. Walter Bright answered:

Why not eliminate the requirement for semicolon statement terminators (unless there are multiple statements per line)? Less typing is "more"!

[W.B.] Because semicolons add redundancy which helps diagnose and isolate common programming errors.

http://forum.dlang.org/post/[email protected]

Personally I do not care. Never perceived them as problem.

[andrewrk]

[W.B.] Because semicolons add redundancy which helps diagnose and isolate common programming errors.

I agree with Walter's conclusion

[mcandre]

Google begs to differ, and they debug a lot of hairy C++ code. They left these out of Go.

[RaphiJS6-13]

The only conflict with existing grammar is the implicit return when the semicolon is omitted.

@andrewrk I suggest reopening or accepting this proposal. The Rust-style block return syntax is gone, so there's no conflict with existing grammar.

[raulgrell]

@RaphiJS6-13 I might have misspoke at the time, I'm not confident that it would not have implications on the grammar or rely on weird parsing logic like JS. Not all semicolons are redundant and even those that are can be useful.

[pfgithub]

some_function()
(variable + 1).doSomething()

This is ambiguous without semicolons. It could be

some_function();
(variable + 1).doSomething();

or

some_function()(variable + 1).doSomething();

[RaphiJS6-13]

some_function()
(variable + 1).doSomething()

This is ambiguous without semicolons. It could be

some_function();
(variable + 1).doSomething();

or

some_function()(variable + 1).doSomething();

@pfgithub No, I meant using line breaks to delimit statements, not automatic semicolon insertion.

[farzher]

some_function()
(variable + 1).doSomething()

shouldn't be ambiguous. nobody's trying to call a function with parens from a newline... i hope