Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get rid of syntactic noise aka semicolons #34

Closed
DartBot opened this issue Oct 10, 2011 · 25 comments
Closed

Get rid of syntactic noise aka semicolons #34

DartBot opened this issue Oct 10, 2011 · 25 comments
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). closed-not-planned Closed as we don't intend to take action on the reported issue type-enhancement A request for a change that isn't a bug

Comments

@DartBot
Copy link

DartBot commented Oct 10, 2011

This issue was originally filed by paulp...@gmail.com


I propose to make semicolons optional, like in Ruby / Python / CoffeeScript.

This is just a noise.

@DartBot
Copy link
Author

DartBot commented Oct 10, 2011

This comment was originally written by eatfr...@gmail.com


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

@DartBot
Copy link
Author

DartBot commented Oct 10, 2011

This comment was originally written by paulpmil...@gmail.com


@#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
Copy link
Author

DartBot commented Oct 10, 2011

This comment was originally written by ladicek@gmail.com


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
Copy link
Author

DartBot commented Oct 11, 2011

This comment was originally written by jat@google.com


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
Copy link
Author

DartBot commented Oct 11, 2011

This comment was originally written by feal...@gmail.com


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
Copy link
Author

DartBot commented Oct 11, 2011

This comment was originally written by mn...@gmail.com


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
Copy link
Author

DartBot commented Oct 11, 2011

This comment was originally written by jat@google.com


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
Copy link
Author

DartBot commented Oct 11, 2011

This comment was originally written by jon.js1.smi...@gmail.com


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.

@DartBot
Copy link
Author

DartBot commented Oct 11, 2011

This comment was originally written by jon.js1....@gmail.com


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
Copy link
Author

DartBot commented Oct 11, 2011

This comment was originally written by riz...@gmail.com


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

@DartBot
Copy link
Author

DartBot commented Oct 11, 2011

This comment was originally written by mprz1024@gmail.com


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
Copy link
Author

DartBot commented Oct 11, 2011

This comment was originally written by mndri...@gmail.com


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
Copy link
Author

DartBot commented Oct 11, 2011

This comment was originally written by drfibonacci@google.com


Added Area-Language, Triaged labels.

@DartBot
Copy link
Author

DartBot commented Oct 11, 2011

This comment was originally written by jat@google.com


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
Copy link
Author

DartBot commented Oct 11, 2011

This comment was originally written by mndrix...@gmail.com


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
Copy link
Contributor

gbracha commented Oct 12, 2011

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

@gbracha
Copy link
Contributor

gbracha commented Oct 13, 2011

Set owner to @gbracha.

@DartBot
Copy link
Author

DartBot commented Oct 23, 2011

This comment was originally written by emurph...@conceptuamath.com


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

@DartBot
Copy link
Author

DartBot commented Nov 12, 2011

This comment was originally written by mar...@algesten.se


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() + ')';

@ivnsch
Copy link

ivnsch commented Feb 25, 2019

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
Copy link
Member

eernstg commented Feb 25, 2019

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

@mpowloka
Copy link

mpowloka commented May 7, 2019

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

@Antol
Copy link

Antol commented May 20, 2019

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

@tofanelli
Copy link

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
Copy link
Member

lrhn commented Jun 18, 2019

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).

@dart-lang dart-lang locked and limited conversation to collaborators Jun 18, 2019
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). closed-not-planned Closed as we don't intend to take action on the reported issue type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

9 participants