My favorites | Sign in
Project Home Wiki Issues Source Code Search
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 34: Get rid of syntactic noise aka semicolons
51 people starred this issue and may be notified of changes. Back to list
Status:  WontFix
Closed:  May 2012

Sign in to add a comment
Reported by, Oct 10, 2011
I propose to make semicolons optional, like in Ruby / Python / CoffeeScript.

This is just a noise. 
Oct 10, 2011
No no, keep the semicolons. It's like removing punctuation from litterature because it's noise. It helps with readability.
Oct 10, 2011
@#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?

I think it's beautiful.
Oct 10, 2011
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.
Oct 10, 2011
What changes would you propose to the grammar ( 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.
Oct 10, 2011
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.
Oct 10, 2011
#6 mndrix
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.
Oct 10, 2011
Automated semicolon insertion, whether in Go or JS, has its own problems.  In JS:

  long expression

doesn't return what you think.  In Go:

if condition

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.
Oct 10, 2011
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.
Oct 10, 2011
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.
Oct 10, 2011
I second this proposal. ; should be optional along with {} for blocks
Oct 11, 2011
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.
Oct 11, 2011
#13 mndrix
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
Oct 11, 2011
(No comment was entered for this change.)
Status: Triaged
Labels: Area-Language
Oct 11, 2011
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.
Oct 11, 2011
#16 mndrix
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 :-)
Oct 12, 2011
Project Member #17
(No comment was entered for this change.)
Labels: -Type-Defect Type-Enhancement
Oct 13, 2011
Project Member #18
(No comment was entered for this change.)
Oct 22, 2011
Keep the semicolons.  Let me indent how I want.  Let me put braces where I want.
Nov 12, 2011
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.sw.getSrs().getName() + ')';

Nov 12, 2011
I'm still not sure what my opinion is on semicolons in dart, and I appreciate your feedback about how they can add clarity to long lines.  While I agree that long lines are occasionally very hard to avoid, I couldn't resist rewriting your specific example below in dart - using string interpolation, turning getFoo methods into foo properties, and taking advantage of the fact that 'this' is not required in dart.  It took me a while to get used to using string interpolation in dart - but once I got over the familiarity curve I have been loving them.

     return '${className}(${},${sw.lng},${},${ne.lng}:${})';
Nov 13, 2011
Project Member #23
You can omit the curlies on the first interpolation:

  return '$className(${},${sw.lng},${},${ne.lng}:${})';

If this statement happens to be in a one line method, you could use an arrow and leave off the return too. :)

Nov 13, 2011
I'm looking forward to a terse future in web development! :)
Nov 16, 2011
please skip this. do _not_ make semicolon optional. 
where is the (anti-star) "dislike" button?
Jan 16, 2012
I'd like to see the semicolons eliminated (not made optional!) and significant whitespace, but failing that...

Braces could be made mandatory on blocks, but with this difference - eliminate the opening brace altogether. If unbraced blocks were disallowed then the opening brace becomes unnecessary, the whole where to put the opening brace religious debate disappears, the code is tidier, and the closing brace still closes anonymous functions and whatnot, filling the gap where a lack of semicolons would have been a problem.

if (xyz) {
  print("opening braces and");
  for (var i in whatever) {
    print("semicolons doing nothing useful");

if (xyz)
  print("tidiest but")
  for (var i in whatever)
    print("with significant whitespace - why don't people like that?")

if (xyz)
  print("still tidier but")
  for (var i in whatever)
    print("without significant whitespace")
Jan 23, 2012
#27 seaneagan1
I don't agree with making semi colons optional in general, however, why not for the last line in a {} block or file ?
Feb 6, 2012
The fact itself that in the year 2012 one has to prove that semicolon is an archaism is just ridiculous. Being forced to type what is obviously implied, as it also is with the `return` statement, just makes me expect all the other design decisions in the language to be as ridiculously conservative. Another Java to replace Java and inadequate people that so viciously defend this absurd. No thanks. Bye bye, Dart.

Feb 7, 2012
Semicolons are wasteful and annoying. If you put one statement on each line 99.9% of the time it should be the default to end statements on EOL. If you once in a while want to write a multi-line statement, it is much less of a hassle to undo it explicitly only those few times.

If you want to build a string over multiple lines you can make a specific exception in that case

a_string = 
"This is an very long string that you really shouldn't " +
"need to build like this in very many situations.\n" +
"What this does is however clear enough."

if a_string.size > 10
  puts a_string
  puts "The string is too short!"

(This is valid Ruby. Ruby doesn't use semicolons)

Not only are semicolons wasteful, they are easy to forget and then they can waste a lot of time debugging! Especially if you have a complex test environment.

They also don't make code more readable, or easy to understand once you are used to not having them sprinkled all over your code. Since your eyes are so used to seeing them, you don't notice them very much. Humans are horrible at noticing  what is not there. If you are not used to seeing a character, you will notice it much more when it shows up.

Make them optional so developers can use their own judgement on their appropriate place. Don't try to enforce a coding style on me.
Feb 9, 2012
Agree with comment 26. I prefer the second way, althrough I fear it a bit. In any case, the third syntax would be great already.

I think semicolons should be eliminated instead of made optional, because it is better to unify things rather than to mantain both a hard and easy way. Besides, Google itself keeps things simple an minimalist. Writing semicolons is a waste of time.
Feb 16, 2012
We have seen at Javascript what "Optional semicolon" means, it's one of the worst parts of Javascript, is one of my motivations to leave Javascript, it has no sense than next code return undefined! And many other buggy and hard-to-see bugs comes from optional semicolons. If you want to absolutely remove them we can discuss it but no optional semicolons.

function getObj()
    prop: 5

A. Matías Q.
Feb 16, 2012
The worst bug ever is the one it's not your fault.

Not to optional semicolons

A. Matías Q.
Feb 16, 2012
I disagree with comment 31 above. Not because I think we should have optional semi-colons, but because the example doesn't make sense. There is nothing "buggy" or "hard-to-see" about the behavior in that example. A language with *no* semi-colons would behave the same way, so if semi-colons were completely removed in Dart, you'd still have that "hard-to-see" code causing a problem-- unless the poster is claiming that it's only "hard-to-see" because you are expecting a semi-colon; but I don't buy that argument. In fact, Javascript, *already* works the way most languages with "no" semi-colons do. Python and Ruby also both have semi-colons, which, for all intents and purposes can be called "optional semi-colons", because they *can* be used to end a line, but they will be meaningless there. 

The problem with the example given above is a fundamental misunderstanding of how syntax works in languages that do not require semi-colons. It's not a bug (can we please stop calling this behavior a bug?), and I don't think it is that hard to see. Again, if you wrote code in other optionally-semi-coloned languages, you would spot this error straight-away. Using this example in favor of removing semi-colons doesn't help the case; if anything, the above example is the argument against removing semi-colons from Dart.
Feb 16, 2012
Project Member #34

Yeah, JavaScript messed it up badly with the confusing "automatic semicolon insertion" rules. Nobody argues with that.

However lack of semicolons is not a problem in the (many) languages that do it right. Try it in a language other than JS--I think you'll find the same sorts of bugs just don't happen.
Feb 16, 2012
I should re-iterate that the only reason someone would find the example in comment 31 "hard to see" is if they did not understand that complete statements end at EOL. "return" is a complete statement. That's not really the fault of Javascript, or any other optionally-semi-coloned language, and we shouldn't have to protect programmers from not properly understanding the syntax of the language they use. When programmers understand the syntax, they are very quick to adapt to a style. Python and Ruby developers would never complain about the above example being difficult to spot-- the error would be obvious because they understand the syntax.

The problem is that Javascript programmers, through a myriad of misinformation and buggy interpreters, don't properly understand what "optional semi-colons" means. It does *not* mean "you can just remove semi colons and the program will always be identical". It means that *newlines are translated into semicolons*, if the statement at the newline is syntactically complete. Python programmers understand this, Ruby programmers understand this. Javascript programmers don't. Again, I attribute this not to the intelligence of the community itself, but the conflicting misinformation stating that "you must always use semi-colons" or "omitting a semi-colon will break the browser". Some of those used to be true, but aren't supposed to be, and, mostly aren't true anymore. I think if the community discussed semi-colon usage in a proper true manner, it would be easy to debunk why examples like the above are bogus and complete non-issues in languages with optional semi-colons.
Feb 16, 2012

Again, this is misinformation. You are incorrectly saying that JS behaves differently than other optional semi-colon languages in the example above. It does not. JS's behavior here is the correct behavior for a language with optional semi-colons. Try it yourself:

In Python:

  def get_obj():
      'prop': 5

In Ruby:

  def get_obj
      prop: 5

Both languages return null or nil. JS's automatic semicolon insertion is very much the same as other languages in this specific case. I'm not sure why people are confusing the facts, here.

For a language to handle the above case correctly, there would have to be explicit handling on keywords such as return, but this would cause a very inconsistent grammar, where something like "return \n {prop: 5}" works but "x = 1 \n -2" does not.

Feb 16, 2012
Project Member #37
Right, but in neither language is that surprising. They start with the general rule: newlines mean end of statement. Then for convenience they add a few cases where the statement continues, but it's unambiguous and obvious when reading the code, such as grouping characters (Python is stricter than Ruby here, which I think is a good thing).

JavaScript is not like that in general. See the first two examples here:

It's subtle but it makes a big difference.
Feb 16, 2012

Oh sure, I understand that ASI's extra rules *can* cause some extra problems, but typically this is not the case. I would be for an ASI that drops the "convenience syntaxes" in favor of consistency, that way there is no more FUD for those uneducated about the syntax. The only problem with JS is that it's not consistent, not that *optional semi-colons* are a problem. Optional semi-colons can work just fine if the rules are consistent.
Feb 18, 2012

As a ruby programmer, it is completely obvious that the code is wrong.
a return on a single line returns nil, there is no situation where it won't (as far as I know)

Maybe it seems otherwise if you are not used to not using semicolons but I can assure you that it is.
Feb 18, 2012

That was my point as well. It *should* be obvious. The problem is that the people here complaining about "optional semi-colons" are really only complaining about some obscure rules in JS's ASI that *occasionally* allows for a statement to continue to the next line. If those exceptions were simply removed, so would the confusion about what a newline means. 

The issue people seem to have isn't with optional semi-colons, it's with the *extra* rules JS has to implement optional semi-colons. 
Feb 18, 2012

Ok, sorry if I misunderstood you. I agree, it is important that the syntax isn't ambiguous no matter if it has mandatory semicolons or not.

When a new line means the end of a statement, there isn't any more ambiguity than when a semicolon does.
Feb 18, 2012
I have a problem specifically with the optionalness. Making them optional means you can write the same code in two different ways without there being any point at all to having the two different ways. For me consistency is king in writing code that maximized readability. So whether they should be there might be a matter of taste, but all the discussion about ambiguity of the rules of the language and the resulting code is a separate issue that just needs to be fixed.
Feb 19, 2012
Semi-Colons should be left in. They are important! Especially in a browser language where there are many different engines for the same code.

Dart already includes some support for dropping semi-colons which I think is fine, but removing them completely is a non-option for me since complex code, or code which is minified to one line will no longer work properly (or at all) if there is no way to optionally specify the end of a line.

I like darts principal of "We are not stopping you from writing terrible code, nobody can stop you from doing that. We are providing you a way to write to write better code"

Although personally I think having semi-colons as optional is dangerous since two lines could be interpreted differently depending on the semi-colon, The compiler does provide Checked Mode which I think allows these people that do use Semi-Colons to avoid the perils of having the compiler treat their code in two different and potentially conflicting fashions.
Feb 20, 2012
(sorry, I send the post before end it)

#33 (@jon.js1.smith)

I said "If you want to absolutely remove them we can discuss it but no optional semicolons". That does not mean I agree with it.


Of course no-semicolons will also have this extrange behaviours, and when I say no semicolons I mean Python style where there are no semicolons by default unless you want it.

With optional semicolons at Javascript style where the argue is "you can use them if you want" gives you to things like:





    name: "Jonh"

I WANT to use semicolons and this takes me to a buggy syntax.

So optional semicolons have two ways to be used:

Semicolons nowhere:
 - cleaner
 - silent spottable bugs
 - code cannot be compressed

Semicolons everywhere:
 - can be compressed
 - noise

Now obligatory semicolons:

 - can be compressed
 - noise
 - bugs at compile time with line number (while the browser loads the code)

Feb 20, 2012
Finally I would like to point than as a programmer I like the single-responsability-pattern.

Semicolon has one responsability: end of sentence.
Line break has one responsability: break the line to make easier to read it.

Without semicolons you load both responsabilities to Line break.
Feb 20, 2012

Again, I maintain that your points are based on a fundamental misunderstanding of JS syntax rules, ASI, and what proper optional semi-colons would mean for Dart. 

There is nothing buggy about the syntax you listed. In fact, the return example often cited as a failing of ASI actually has nothing to do with ASI. The grammar for JS specifically does not allow for a line break after a return keyword, you can see this for yourself [1]. The reality here is that return doesn't work the way *you* want it to, not because of ASI, but specifically because ASI is not being allowed here. I'm not sure of the details of why exactly ASI is not being allowed in this location (there are probably weird ambiguities), but it *could* be made to work with ASI. To reiterate, the reason you think the return example is weird is *not* because of ASI, but rather because ASI is not used here. Note that I personally like the existing behaviour, as it is more in line with how I would expect a language with optional semi-colons to work, but that isn't really the point.

The other points you seem to be trying to make are that: 

Myth 1. A language with "no" semi-colons cannot be compressed

Wrong. I assume you are talking about minifcation, not compression, as any code can be "compressed" using traditional compression mechanisms (like gzip). First off, I should take the opportunity here to point out how ridiculous minification is as a requirement of a language. Frankly, the fact that JS needs to be minified is a horrible failing of the language, not a feature. A high level language shouldn't be designed around its ability to be obfuscated or minified; I think most people can agree that this should not be a priority for Dart.

But even if you want to assume minification is necessary, it is still an incorrect assertion. There are two reasons. Firstly, because you are assuming that minification would need to mean removal of newlines-- it does not. In a language where newlines equal the end of a statement, you don't actually end up saving any bytes by replacing a newline with a semi-colon. So in reality, minifying a language with no semi-colons would actually be easier than a language with mandatory semi-colons, since there's nothing to minify with respect to line endings. But even if you did want to, for some reason, "remove" newlines, you could still do so by replacing them with ";" (assuming the statement ends at that point, otherwise you just remove the newline and don't replace it). Code in these languages can be minified in the exact same way JS can-- I don't know of any technical reasons why this is not true.

Now, a language with *significant whitespace* could not be minified as easily, so maybe you were trying to make that point, but optional semi-colons have nothing to do with significant whitespace, so I don't see the correlation. That is a completely different issue

Myth 2: Obligatory semi-colons let you see bugs at compile time with a line number, whereas no-semicolon languages do not

I don't see how this is true. Remember, line endings are not a magical thing in languages with no-semicolons. Parsers can detect line endings just fine in these other languages. Forcing semi-colons does not make the parser any better at detecting a line ending, it just makes the grammar easier to construct. Once the grammar is constructed, though, the parser will do what it is the parser does, it doesn't care about whether or not a semi-colon or a \n (at a lexically complete state) denotes the end of a statement.

Myth 3: It's hard to see bugs if semi-colons are optional/non-existent

Bogus. Again, this is probably just a subjective description of your comfort level in spotting these bugs, but if you understood and had experience with languages that have "no" semi-colons, you would be very quick to spot the problem with your "return" example. As someone who works with languages of both styles, I can say that I personally have no issues spotting syntax errors in either language. If *you* have problems with this, maybe you should use an IDE that will tell you about such common errors. Note that any IDE worth anything can warn you about "dead code"; the return example should give such a warning in any decent IDE, since the JSON object never gets executed due to the return. Other heuristic based warnings could let you know of poor style.

I should point out, on a sidenote, that you should really not "want" to use horrifically bad styles. I don't know any language that advocates the following syntax as a valid idiom:

  { ... };

Or even:


To me, this looks wrong in just about any language, and I question whether your code would *actually* look like this if it was legal in JS. I would have done a search on codesearch to verify how often you see code like this in the wild, but it seems codesearch was finally shut down. I guess it's not my place to comment on how people want to code, but frankly, I really don't see why anybody would be so vehemently in favor of inserting a newline between return and the expression to the point where it is an absolute requirement of the language syntax.

As far as SRP goes, you are mangling your metaphors. SRP has nothing to do with syntax, it has to do with design elements. From a syntactical point of view, there's absolutely nothing wrong with having a syntax that "does more than one thing", in fact, this is what we call "syntactic sugar". There are a boatload of syntaxes in JS *and* Dart that violate "syntactic SRP"-- the most obvious: parentheses have many different responsibilities, one being precedence grouping, the other being method call syntax-- so should we make parens only have a single responsibility too? I really don't buy this argument.

[1]: -- look for "returnStatement"
Feb 28, 2012
Some reasons why I vote for semicolons to stay:

* In human perception, a new line is not only a line ending, but an element of stucture and organization. To emphasise the end of a statement, a exclusive line delimiter (like semicolons, you guessed it!) is very helpful. As it is in normal written language.

* You _can_ put multiple statements on one line if you wish so. Freedom of choice.

* It is easier for programmers of other languages to adopt to Dart.

But hey, freedom of choice. I can see why some folks would like to get rid of them, so why not make them optional?
Feb 29, 2012
after reading all the comments people seem a bit confused.

python uses 'significant whitespace' for some things, like what is in a cirtain loop and when the loop ends etc...

in java and the current dart, the '{' and '}' are used for such things, nullifying this issue.. this thread is not about removing these brackets from the grammer and relying on tabs/spaces instead.

What we are talking about is how to designate line termination.
in python and others it is an unescaped '\n'
in java or (currently) dart it is ';'

What is very clear is that in a language like java, ';' is practically always followed by '\n'

I do not think anyone would refute this.

So let us remove or optionalize the ';' and simply rely on an unescaped line feed that is there anyway.

for a large number of characters in a statement, python allows escaped new lines to continue a single statement into multiple lines.

minimizing syntax without losing functionality or readability is great... for those who instinctively put the ';', make it easy for them and make it optional.
Mar 1, 2012
tl;dr: you don't like them, fade them away. 

I don't enjoy semicolons and was very happy, thanks to Ruby, to discover that they can be avoided most of the time. That Javascript allowed that too was a nice surprise.

If I were to decide, I would make \n terminate all statements and use \ for the rare cases where a statement continues on multiple lines.

Yet, is it really a big deal considering the fact that most modern editors can customize their color scheme in such a way that one can reduce the constrast of punctuation to reduce "noise"?

BTW: I wonder why most color schemes assign lower constrast to comments then to code, try doing the opposite, you may be challenged by the result and decide that "high constract comments" rock.

Mar 18, 2012
The programming language Groovy does not need statement endings with semicolons as well. I agree the semicolons should be optional.
Mar 28, 2012
I vote for making semicolons optional.  I've been using CoffeeScript for a while now and the thought of having to continually add that syntactic legacy is enough reason for me to overlook Dart.  Modern languages don't need it.
Apr 9, 2012
Another vote for optional semicolons, like newer languages Go, Ruby, Scala, Groovy and Gosu, even though I've mostly coded in semicolon languages C,C++,Java for ~20 years.
Semicolons could be required in a more strict runtime mode, perhaps, for some purists.
Apr 30, 2012
Project Member #55
(No comment was entered for this change.)
Labels: apr30-triage
May 1, 2012
Project Member #56
(No comment was entered for this change.)
Labels: -apr30-triage
May 1, 2012
Project Member #57
(No comment was entered for this change.)
Labels: triage1
May 2, 2012
Project Member #58
(No comment was entered for this change.)
Status: WontFix
Labels: -triage1
May 3, 2012
Project Member #59
This issue is simply religious. We'll never satisfy everyone; feedback is all over the map. Ultimately, we need to be consistent and settle the matter once and for all.
May 3, 2012
Project Member #60
We have decided not to support optional semicolons for the following reasons:
- White space should not have semantic impact.
  In JavaScript the worst problem related to this is around return.
  This will return undefined which is completely broken.
- Dart programs will be become more consistent and therefore easier to read. 
May 3, 2012
Groovy + CoffeeScript it is then.
May 3, 2012
personally, I have lost interest in dart because of the syntax.
May 3, 2012
Insisting on the semicolons makes me shake my head in disbelief. I program mostly in Groovy these days and never missed the semicolons nor ran into any confusing ambiguities.

I think it's safe to state that 99% of the semicolons Dart programmers will write and read will be redundant boilerplate. I doubt I'm the only one who feels like every time I write a stupid(=redundant) semicolon a fairy dies. I suggest you reconsider how much respect you want to show for our eyes and pinkies. 

The constant annoyance of typing semicolons is a big deal for a language with mainstream ambitions. If you ignore it somebody will eventually create 'CoffeeDart' or 'LessDart' (or whatever) which I would find quite embarrassing for a fresh and innovative programming language. 
May 3, 2012
optional semicolons would satisfy everyone.  if you don't wanna use them, don't... if you want to.. fine.

as to your return statement which you say is a problem:

new line would end the statement, so there is no ambiguity.  if you don't want the new line to end the statement, you would need to escape it.
Delete comment Comment 65
May 3, 2012
I happen to prefer optional semicolons, but the fact that we can't even come close to a consensus here suggests that there is no "right" answer.

For those who say they would give up Dart over this tiny matter of syntax -- go paint your own bicycle shed.  ('s_Law_of_Triviality)
May 4, 2012
> I program mostly in Groovy these days and never missed the semicolons nor ran into any confusing ambiguities.

Do you? Because I've ran into issues (well, one issue) with optional semicolons in Groovy several times, always when using "fluent interfaces" like so:

I strongly prefer having the dot at the _beginning_ of the line, so that it's visually obvious that this line _continues_ the statement and doesn't start a new one (and that's one of the reason I'm against optional semicolons, even though I know that this exact issue can be solved by adding a special case to the "semicolon insertion" algorithm, as for example Ruby does since 1.9, I think).

Funny thing about Dart: I've seen a recommendation in one of code reviews (can't remember which one now) that the dot should be at the end of the line, should Dart get optional semicolons some day (it was said "the style is" or something like that, but I couldn't find it in the style guide). Yet for method cascades, every multi-line example I've seen put dots at the beginning of the line. Dart people should put their style in order :-)
May 4, 2012
> Do you? Because I've ran into issues (well, one issue) with optional semicolons in Groovy several times, always when using "fluent interfaces" like so:
>      .bar()
>      .baz()
>      .qux();

Do you *actually* run into these issues? Or are you just being hyperbolic? Because, if you actually run into these issues, you clearly don't understand Groovy syntax. The statement was that Groovy does not introduce "confusing ambiguities". I'm not entirely familiar with Groovy syntax, but if the above doesn't work, it seems to be neither confusing nor ambiguous as to why. If you are confused or feel as though it is ambiguous, you need to re-read the documentation on syntax. summarizes quite well:

> "If the end of the line is reached and the current statement is not yet complete it can be spanned across multiple lines."

Look at your code again and internalize this rule, it should be very clear why that code is wrong.

Humans are not stupid. We can learn and understand complex concepts very quickly. This is not even a complex concept. There's no reason to pretend that every Dart programmer is too stupid to internalize basic syntax rules. Sure, it's not the same syntax as Java, but again, we're not idiots, we can figure that out pretty fast. Presumably, even if you ran into the above issue in Groovy, you shouldn't have run into it more than once.

And more importantly, Dart is trying to replace Javascript, not Java, so optional semicolons should not be a new concept to this demographic. The argument that this is confusing to Java programmers is irrelevant-- by that standard, people should be tripping all over Javascript. I've never heard of such complaints. I've only seen people unaware of ASI who quickly adapt to the new syntax.
May 4, 2012
By the way, regarding your preference of "dot notation beginning a line", there are better ways to solve this problem. Adding a "with" keyword (which to my surprise I found out that Javascript already has, so this wouldn't be a new feature to those switching over) would be one of them, and is probably a cleaner way to organize your code anyway.
May 4, 2012
Groovy pretends to be almost Java, and a lot of people (me included) use their Java habits in Groovy. This is a fail. I _do_ understand Groovy syntax, I can even understand JavaScript syntax, but I'm not going to adapt to weird rules. (Btw, I found Groovy wiki to be extremely old and inaccurate, nothing to rely on).

Also, JavaScript programmers are not the only target group of Dart. Dart targets Java and C# programmers as well -- I've even said in my Dart talk back in december that "Dart is JavaScript for Java people". Confusion to Java programmers is extremely relevant here. (I personally think that Dart has the potential to not only replace JavaScript in the browser, but also Java on the server. And Dart certainly competes with Node.js, which a lot of Java developers started to be interested in lately.)
May 4, 2012
JavaScript already forbids "with" in strict mode, and they probably know why. (One of the reasons is performance, because "with" introduces dynamic scoping, but there are others.)

For better "code organization" (for whatever that means), Dart has method cascades. And they look like


So it has the same problem with regards to semicolons :-)
May 4, 2012
#75 david.bernard.31
In Scala semi-colon are only use when you want to put several statement on a single line (ex{ x => doStuff1(); doStuff2() })

I also prefer the dot at the begin of line, to workaround the issue, I simply put paranthesis around the statement, as is the statement is not end with the end of line.
Aug 12, 2012
Project Member #76
 Issue 4461  has been merged into this issue.
Sign in to add a comment

Powered by Google Project Hosting