Meta-issue for discussion of the proposal to make semicolons after statements optional

[leafpetersen]

This issue is to provide a forum for community discussion and feedback related to the proposal to make semicolons optional after statements.

This entry will be updated when a proposal is available.

cc @munificent @eernstg @floitschG @lrhn

cc @Hixie

[brianegan]

Just my 2 cents, but coming from a JS / Android background, I'd love either "Semicolons - YES" or "Semicolons - NO".

I do not think OPTIONAL semicolons are healthy for a development community for two reasons:

1. It will lead to needless bikeshedding. Just witness / read up on the endless debate in the JS community over whether or not to use them. So many hours wasted over something purely stylistic. These debates do not help us solve actual problems.
2. Additionally, it will make reading code harder for beginners, because it will introduce a stylistic distinction that might not be as easily understood by newcomers.

To keep an open mind, I'd love to hear more about the reasoning in support of optional semicolons. Do folks feel it will help adoption? Is it a stepping-stone toward a Dart v3 w/o semicolons?

[Hixie]

The bikeshedding in the JS community isn't over something purely stylistic. Semicolon insertion in JS (and some other "optional semicolon" languages like Kotlin) can have very dramatic effects on the semantics of the code. For example, consider:

// Javascript
function test() {
    return 1 + 1
             + 2
             + 3
}

console.log('Hello, world! ' + test());

// Kotlin
fun test(): kotlin.Int {
    return 1 + 1
             + 2
             + 3
}

fun main(args: Array<String>) {
    println("Hello, world! ${test()}")
}

What do you think they print?

[Hixie]

(I am reserving judgement on the issue when it comes to Dart until there's a concrete proposal.)

[sethladd]

Make it an error to have statement continuations after the return line. Also, I'm curious if there's actually a problem here, given what go, kotlin, and swift have been doing. Do they report this as a static warning or error?

I am not worried about "two ways to do it", there are infinite ways to do most formatting and conventions. I am confident that the combination of automatic formatters and style guides (both global and local per-team) will create cultural norms here.

[brianegan]

@sethladd Before we talk about all the tools that could be built to support this, could you maybe just elaborate a bit about what you see as the user benefit? How will this help us write better programs as a community? What "user need" is it targeting / solving?

To be clear: I prefer languages without semi-colons, but I just don't quite see what this will add to the Dart community or how it will help the ecosystem overall, and that's what I'm trying to understand a bit.

I'll await the proposal to see if it answers those Qs :)

[sethladd]

Modern languages are generally believed to be less boilerplate, more terse, and including language features working for you. For example, type inferencing is the language working for you. We could force you to right type annotations everywhere, or we can say "in many cases, we can infer it for you". Auto-inserting punctuation is another way the language can work for you. Also, there's an element of being seen as a light-weight, modern language and staying competitive. The trend in languages was to go to var, to go for closures, to go for => functions, and now to go for implicit semicolons (done right, of course).

[Hixie]

The code above is valid in Javascript and Kotlin respectively. (But the important question to me is, can you guess what they print?)

I think "make it an error to have statement continuations after the return line" is a perfectly valid part of a complete proposal, but I'd need to see the complete proposal before I could really say how valid it is.

BTW, omitting punctuation isn't new. Perl, Fortran, even COBOL all had stuff like this. Lisp didn't even have semicolons. I would hardly say it's a sign of a modern language.

[sethladd]

I would hardly say it's a sign of a modern language.

Re-modernizing? But yes, good point, plenty of languages pioneered here.

[Hixie]

In fact, Perl went even further and allowed you to omit the (/) around function arguments, if you want to really have the language "work for you". You can write entire programs in Perl using nothing but a-z and whitespace. I'm not sure I would take that as a point in favour of the language, though. The work Perl does for you when writing the code is work you have to pay back in spades when reading the code, to the point that Perl has often been referred to as a write-only language. Readability is infinitely more important than writeability.

[ds84182]

So there are several problems that arise if Dart removes the semicolon requirement:

With semicolons:

print("hello");
() { print("goodbye"); };

Without semicolons:

print("hello")
() { print("goodbye") }

The first example would just print "hello", the second example could either print "hello" or throw an error, depending on how it's interpreted by the parser.

This can become worse if someone does this:

returningPrint() => print
() { print("goodbye") }

Now, instead of the function returning print the function tries to return the result of print(), which isn't a valid function call.

There would be a lot of ambiguity introduced by closure syntax... who says it's a call + block or a closure?

[sethladd]

How do swift, go, and kotlin handle these cases?

[Hixie]

Go has a crazy syntax for lambdas which is whitespace-sensitive (you can't put a line break after the arguments before the return type, or some such). They also have a reserved word before the lambda which disambiguates between closures and calls.

Swift and Kotlin use braces for closures. I haven't quite figured out the syntax exactly. Kotlin, as previously mentioned, makes choices that make its semicolon-insertion confusing and bug-prone.

[zoechi]

If there is a simple way to get rid of all ambiguities, then getting rid of semicolons would be great of course.
If getting rid of ; hurts for example autocompletion, I'd rather keep ;.
Making ; optional only for most cases seems more like an approach to appeal to JS developers to me, like Dart tried at the beginning with it's optional types, to then later move to strong mode because the original approach limits language development and most developers prefer good feedback from the tools anyway, which in the end could mean optional ; might hurt more than it helps (as already hinted to by @brianegan)