Get rid of syntactic noise aka semicolons about sdk

[DartBot]

This comment was originally written by [email protected]

---

No no, keep the semicolons. It's like removing punctuation from litterature because it's noise. It helps with readability.

[DartBot]

This comment was originally written by [email protected]

---

I'm fairly certain that most programmers who work with those languages (Go, JS) on a daily basis are aware of the "pitfalls" of ASI. I personally don't see these as pitfalls, since the grammar is quite clear and unambiguous about why "return\n foo" does what it does-- and if you acknowledge that a newline is a line ending like a semicolon is, it should really not be surprising at all. But I suppose this is ultimately what is up for debate.

That said, I don't see this as a reason in itself to be against ASI. It's important to realize that while forced semi colons are "familiar to many programmers", many programmers (I would say an extremely large population in this context, since we're primarily including the JS community here) are also very much familiar with ASI and optional semi colons. They aren't a new concept, and they are used in many languages-- JS and Go were named, but there are other languages that implement this in varying capacities too, like Scala, Ruby, Smalltalk. I'm not sure these other programmers appreciate being shunned in favor of treating the C*/Java users like first class citizens here, that seems to be what is happening.

Finally, I just want to say that I don't think we need to argue readability of programs with optional semicolons. If you've spent any amount of time writing programs in a language with optional semicolons, you likely understand why this is such an important point for many of the users coming from those languages. The reduction of semicolon noise is extremely significant, especially in a scripted world where lines are typically shorter than they are long. It's unfortunate to have to talk in terms of aesthetic choice when adopting a language, but aesthetics remains a reality in adoption, and I'd bet most newcomers from ASI-supporting languages would see this as quite a hurdle to proper adoption and acceptance of Dart as the future of the web. You're effectively telling all these JS programmers that the way they've been coding for years was outright wrong, and they are sitting there scratching their heads, because their code worked just fine-- and looked cleaner, too.

[ivnsch]

Very sad that this was closed. After having been working with Swift and Kotlin a few years, I don't see the need for semicolons at all. They just add noise. Typescript and many other modern langs don't require them. The code looks way cleaner and easier to read without.

[eernstg]

@i-schuetz, to follow this topic today you need to look in the right place: dart-lang/language#69.

[mpowloka]

Is there any chance this will be reopened? Semicolons make Dart awful in comparison to languages like Scala or Kotlin.

[DartBot]

This comment was originally written by [email protected]

---

@#c1 not to remove, just to make them optional.

Code is a literature too. But it has different punctuation, it's called indentation. All developers do use indentation, even when it has no meaning in the language.

Do you think that this code is unreadable? http://jashkenas.github.com/coffee-script/documentation/docs/optparse.html

I think it's beautiful.

[DartBot]

This comment was originally written by [email protected]

---

I'd also like to express my opinion that semicolons should be kept, if only for syntax errors handling and recovery. Significant whitespaces are just bad idea for a lot of people.

[DartBot]

This comment was originally written by [email protected]

---

What changes would you propose to the grammar (https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/language/grammar/Dart.g) that would make semicolons optional? I suspect you will find more hacks are required to make the grammar unambiguous.

Personally, having semicolons is far less painful that having semantic whitespace, as in python. The semicolon marks a clear end to the reader (and to compilers/IDEs as well, which gives much better error recovery), and the flip side of leaving it off is you wind up having to do ugly things like adding an unnecessary pair of parens and putting one on the previous line when you need to span multiple lines. Long nested blocks are also problematic to line up with only indentation level to go by.

[DartBot]

This comment was originally written by [email protected]

---

Relying on white-spaces to parse code - no thanks. The readability improvement is too big to disregard, because you know - sometimes you aren't working on your 24" monitor.

[DartBot]

This comment was originally written by [email protected]

---

Go has optional semicolons without the headaches of significant whitespace. They're handled by the lexer. Presumably, Dart could do something similar. I agree that making semicolons optional is a readability improvement. For those who want explicit semicolons, they can still add them.

http://golang.org/doc/effective_go.html#semicolons
http://groups.google.com/group/golang-nuts/browse_thread/thread/5ee32b588d10f2e9

[DartBot]

This comment was originally written by [email protected]

---

Automated semicolon insertion, whether in Go or JS, has its own problems. In JS:

return
  long expression

doesn't return what you think. In Go:

if condition
{
   stmts
}

doesn't do what you think either.

My personal feeling is if you want to make semicolons optional and avoid these problems, you have to change the grammar. However, it isn't clear you aren't getting something worse than the syntax common to languages familiar to many programmers.

[DartBot]

This comment was originally written by [email protected]

---

FWIW, I would even be willing to compromise and suggest using the Python-style "" line suffix to unambiguously denote that a statement was continuing to the next line, if it was the only way to get a consensus on ridding the world of all those unnecessary semicolons... but I am probably in the minority on that kind of a direction.

[DartBot]

This comment was originally written by [email protected]

---

I second this proposal. ; should be optional along with {} for blocks

[DartBot]

This comment was originally written by [email protected]

---

On one hand, I do think semicolons are line noise and should be optional. On the other hand, both significant whitepsace and optional syntax are two features abhorred by some. For example, I can take optional semicolons, but I wouldn't want parens or braces to be optional because the former is ugly and the later is error-prone. I don't recall having ran into non-brutally-obvious bugs due to the optional semicolons in Javascript.

[DartBot]

This comment was originally written by [email protected]

---

Google is well positioned to add some data to this discussion: crawl a sample of JavaScript files in the wild and analyze what percentage of real world functions are affected by JavaScript ASI bugs. ASI might cause problems for programmers, but until we know the magnitude it's hard to make a sound decision

[DartBot]

This comment was originally written by [email protected]

---

Added Area-Language, Triaged labels.

[DartBot]

This comment was originally written by [email protected]

---

How do you propose executing all the world's Javascript and seeing if it has ASI bugs? That sounds like the halting problem to me, aside from the issue of knowing what the intended behavior was.

[DartBot]

This comment was originally written by [email protected]

---

True, we can't definitively spot ASI bugs, but we could recognize common patterns that are likely to be incorrect. For example, in a large sample of JavaScript, what percentage of return statements are of the form "return\nlong_expression"? How often are semicolons omitted before a line that starts with an open paren? How often before a line that starts with an open bracket? Those are three of the most commonly mentioned problems with JavaScript's ASI rule. If one had a rough estimate of their prevalence, one could make a more informed design decision.

Another useful metric might be, what percentage of JavaScript lines trigger the ASI rule at all? JavaScript developers can omit semicolons today if they want to. It would be useful to know how often they do it. If 95% of existing JS code uses explicit semicolons, there's no reason to support ASI in Dart. If the number were 50%, one might conclude differently.

Without data of this sort, either decision is arbitrary. Of course, semicolons won't decide Dart's fate, so it may be a moot discussion anyway :-)

[gbracha]

Removed Type-Defect label.
Added Type-Enhancement label.

[gbracha]

Set owner to @gbracha.

[DartBot]

This comment was originally written by [email protected]

---

Keep the semicolons. Let me indent how I want. Let me put braces where I want.

[DartBot]

This comment was originally written by [email protected]

---

Please keep semicolons. I know very long lines probably indicate I should restructure the code, but they do happen.

That's why I don't buy above coffee-script example and significant white space has been a bad idea ever since Makefile - don't go there.

    return this.getClassName() + '(' + this.sw.getLat() + ',' + this.sw.getLng() + ',' + this.ne.getLat() + ','
        + this.ne.getLng() + ':' + this.sw.getSrs().getName() + ')';

[Antol]

Say NAY to semicolon!
Any explanation from contributors why in 2019 do you still need a semicolon?

[tofanelli]

Ok then.... i do hate the need to put semicolons in the end of the line too, so, if the Dart team wants to keep this semicolon, at least make the linter auto add it and the auto complete as well. Done. We won't need to bother about it again...

Make it optional would be much better, but auto add is almost good...

[lrhn]

Any explanation from contributors why in 2019 do you still need a semicolon?

This feature is now discussed in dart-lang/language#69 and dart-lang/language#72. Please post any new comments in those threads.

The short answer is: Because the Dart grammar, with it's C/Java roots, adjacent identifiers in declarations and overloaded operator meanings, makes it hard to omit semicolons without making the end of statements ambiguous and unparsable to the compiler (and/or to the user, depending on how the necessary heuristics are tweaked).