Language: Optional Semicolons

[mit-mit]

Many programming languages (incl. TypeScript, Swift, and Kotlin) support omitting semicolons as explicit statement separators. We consistently hear from developers who come to Dart from those languages (for example, to implement Flutter apps), that they find the mandatory semicolons irritating & pointless. In addition, removing the need for terminating statements with semicolons would also support our overall goal of reducing boilerplate, and making Dart as terse as possible; however we need to be mindful of also keeping it readable, unambiguous, and unsurprising.

Current status: After a longer investigation we have currently put this on hold, as a reasonable implementation of this would have to involve some rather large syntax changes to the language. Please see the detailed write-up for additional information.

[yjbanov]

I love the idea of optional semicolons :+1:

However, I think this issue is missing a problem statement. Pointing to other languages is useful, but those are _solutions_ to a problem. They do not describe the problem.

[mit-mit]

Updated the description. This will be covered in much more detail in the actual proposal.

[mit-mit]

Related SDK issues: https://github.com/dart-lang/sdk/issues/34, https://github.com/dart-lang/sdk/issues/30347

[feinstein]

Maybe there could be additional syntax to avoid ambiguity, only in cases where it could lead to ambiguities, something like:

code ---
code;

Or

;;code 
  code;

[munificent]

Definitely, there are always ways to avoid the ambiguity. Parenthesizing an expression or removing a newline is usually sufficient.

The issue is more around whether the user finds those ambiguities intuitive and considers the workarounds reasonable. (JavaScript is a good example of a language that has workarounds for its newline ambiguities, but those workarounds are so confusing and onerous that most users just use ; instead.)

[egdelgadillo]

I agree, this should be a feature

[korgara]

Optional semicolons is the first step to fuck up the code style if you are not only one developer on the project.
I saw a lot of JavaScript projects and it feels like scratching your eyes, when there is semicolon on one string, and there is no on the next similar.

[egdelgadillo]

Well, it can then be project wide toggable, Could be an option in one of the project config files, so all the code stays even. This would mean that if it's deactivated, using semi-colon to end a line should raise an exeption too, same for the opposite if semi-colon is activated in the current project

[munificent]

I saw a lot of JavaScript projects and it feels like scratching your eyes, when there is semicolon on one string, and there is no on the next similar.

We have already have an automated code formatter, dartfmt, that is in wide use. If we do optional semicolons, dartfmt will remove them and the code will stay consistent.

[Buerkut]

When I got in touch with dart at two years ago, I always have a question about the semicolons for two years while using dart for coding.

In Golang and many other languages, the semicolons are optional and I think it's a good idea. The mandatory semicolons at end of each line are really redundant in dart. And I think if in some conditions the semicolons are essential, we maybe could find a replacement. Such as in an abstract class in dart:

abstract class Animal {
  void cry(); // cry is an abstract method because of absence of method body and the end semicolon.
}

It can be written as:

abstract class Animal {
  abstract  void cry()  // omit the end semicolon by using 'abstract' as a replacement.
}

If the semicolons at the end of every line could be omitted, it will be more effective and more terse than now. And the IDE will not report an error again when writing a new line that is uncompleted with a semicolon.

I really hope the semicolons could be optional at the future sdk versions.

[jamesporter]

I find the semicolons in Dart _extremely_ tedious (as a developer coming from TypeScript, Swift, Kotlin and other languages), in fact in first few days with Dart about 50% of failures to compile turned out to be a missing semicolon.

While I would love if if Dart made them optional, perhaps dartfmt could insert them in 'obvious' cases? I imagine this is somewhat hard, but Prettier does it reliably (to the extent where I don't mind semicolons in TypeScript/Javascript as Prettier writes them for me).

[nayan2823]

Two things i want to mention that would make code Dart likely fun

1. Remove the semicolons :- All new langauges have removed semicolon . coding dart reminds me of java days. For readibility mordern code editors automically format code .

1. Convert switch statement to when like in kotlin its more readable and take less code write.

[munificent]

I did a bunch more investigation of optional semicolons after writing the "Terminating Tokens" proposal. I wrote up my thoughts on the experience here.

[rodolfoggp]

I started learning Dart this week and was quite surprised to know that it requires semicolons.
In all modern languages like Kotlin, Swift and Go, you can omit them.
I thought these days of old verbose programming were over...

[tatumizer]

loveManifesto() {
  ;;   ;;;     ;;;;;;  ;;   ;;  ;;;;;;    ;;
  ;;   ;;;     ;;  ;;   ;; ;;   ;;;;       
  ;;   ;;;;;;  ;;;;;;    ;;     ;;;;;;    ;; 
                                         //
}

[tatumizer]

One of my points (that you chose to ignore), which is very relevant to this topic's discussion was that I suspect (but can't prove) that the weirdness of some K-n's expressions is related to optional semicolons. With optional semicolons, it's difficult to determine how to handle certain symbols (this was mentioned here). Which illustrates my earlier hypothesis that the war against semicolons comes with a very high price, which doesn't justify questionable benefits resulting from semicolon removal.

[i-schuetz]

In almost 2 years of working with Kotlin (nearly full time) I haven't had problems because of semicolons _a single time_. On the other side, in less than a month of working with Dart, I had already 2-3 occasions where I spent a while fixing compiler errors because of them. So at least based on my own experience, they seem unnecessary and rather a hindrance. And ugly, of course.

[tatumizer]

You completely misunderstood my point.

[i-schuetz]

Oh. Right. You're saying that you suspect that some Kotlin expressions are weird because of its optional semicolons. I also suspect many things, but wouldn't bring that up in an argument with nothing to back it up.

Also, considering your (completely subjective) negativity towards Kotlin, as could be read in the deleted conversation, it's most likely pointless to argue about this "weirdness".

And why focus on Kotlin? Plenty of other langs seem to be doing quite well without semicolons, including Haskell, Scala, F#, Typescript, Ruby, Swift and matlab, among others. Are those "weird" too?

[tatumizer]

You have to ask the developers of the languages how much they regret making semicolons optional.
And you have to ask them privately. Method overloading also looks like a nice feature, until you find out...
Currently, too much of s/w engineering is driven by fashion alone.

[leafpetersen]

Thanks for taking it offline and cleaning up. I realize feelings run high on some of the issues we discuss, but we really need to keep the discussions here technical and professional if we're going to continue to use this as a primary venue for doing design work.

[yisar]

There are no semicolons in almost all modern languages, and dart's semicolons surprise me.

I'm glad to see this vote. It's clear that there are few opponents.

[munificent]

It's clear that there are few opponents.

Yes, I think most users want us to eliminate the semicolons. The hard point is designing a method for how to do it, and so far we haven't been able to come up with a set of grammar changes simple enough to feel confident in shipping it.

[Hixie]

According to our Q1 survey, about 40% of our users think removing semicolons is worth the cost of a breaking change, 41% if there was a way to do it automatically. Contrast to 47% who think non-nullable types are worth it (51% if it could be automated), 55% who think real Unicode support in strings is worth it (56% with automation), 47% who think renaming types to make them consistent is worth it (55% with automation), and 16% who think that no change could be worth breaking backwards compatibility (13% think no change could be worth breaking backwards compatibility even with tooling).

So at least as far as Flutter goes, it's not the case that most of our users would rather we did this.

[i-schuetz]

Is there any Dart feature where there was a substantial majority (above 60%)? From this data, it sounds like people just don't like breaking changes. In which case 40% would still be relatively high.

A more to the point question would be simply whether we prefer semicolons or no semicolons. It's then up to the results of the other features, the cost of implementing the change, the available capacity, etc. to decide if and when it will be done.

FWIW to me personally this shouldn't be high in the priority list - it's a cosmetic improvement, that doesn't have an impact on safety or architecture and a minor one on verbosity. Things like proper optionals, ADTs, data classes, pattern matching, etc. are more important. It would still be nice to have, at some point.

[mnordine]

According to our Q1 survey

@Hixie Which survey was that and how did you advertise it? I hope it's not a Flutter-only survey that excludes all other Dart developers, was it? I usually keep a close eye on things in the Dart community, but I didn't see anything.

[Hixie]

When I say "our" I mean "Flutter's" (I'm the Flutter TL), sorry for any ambiguity.

FWIW, in the same survey about 80% of the respondents said they would like breaking changes in general if it improved APIs. The numbers above are the numbers for the specific ideas we asked about. We hope to have a blog post out soon with more details on the results of the survey. The survey is advertised in Flutter channels such as the flutter mailing lists and our Twitter feed.

[munificent]

That's good data to have, but is somewhat confounded:

• (As far as I know) it only polls existing Flutter users, so has survivorship bias.
• It frames it in terms of a breaking change, which implies a level of pain that might not be true for how the feature is actually shipped. For example, optional semicolons was technically a breaking change in Go when they shipped it, but I don't recall many users feeling that way about it. A sufficiently smooth migration path is indistinguishable from a non-breaking change, I think. At the very least, there are certainly shades of gray between "breaking" and "non-breaking".

But, in general, yes, optional semicolons aren't a clear huge win.

[mnordine]

When I say "our" I mean "Flutter's"

Yeah, that was my worry. I understand it's a priority for you, and I don't mean it personally of course, but applying Flutter-only polls to general language issues excludes a ton of users, who also use it in non-Flutter contexts (thus giving a more complete picture). Why not poll all Dart users instead of just a subset of them in the first place?

[Hixie]

I welcome other sources of data if we have any. I'm just reporting on the data I have. I personally am pretty neutral on the whole topic so long as it doesn't break patterns like the ones I've mentioned before, such as:

  return _convertToPixels(margin.left * (widget.leftScaleFactor ?? 1.0))
       + _convertToPixels(margin.right * (widget.rightScaleFactor ?? 1.0))
       + innerImage.padding.horizontal
       - size.width * 2.0
       - 8.0;

[yisar]

Whenever there is a new proposal, it's a good thing to have optional semicolons, and the voting results are obvious.

But somebody always comes out to stop it.

Maybe some people think that aesthetic improvement is not a great victory, and there should be no high priority.

But judging from the voting results, most people still look forward to improvement.

There may be some border situations that need to be dealt with, and I will support them, but don't try to ignore them and prevent them from progressing.

[munificent]

prevent them from progressing.

I don't think this is the right mental model to have. The language doesn't progress spontaneously on its own. It requires a lot of hard work designing proposals. The main reason optional semicolons aren't going forward right now is because no one has been able to come up with a clean, precise proposal that works well enough for them. In the absence of that, there is no way to progress, but it's not defined what we would progress to.

[hlung]

Please make this real. #prayforoptionalsemicolon

[tedhenry100]

I'm very happy that semicolons are mandatory in Dart code. It makes the code much easier to read. The end of statements (possibly spread over multiple lines) is something I never need to figure out thanks to the explicit semicolons.

[hlung]

@tedhenry100 I have been working with Swift (which has optional semicolon) for more than 3 years now and for me I have no readability issue. A newline is enough to signify end of a statement, no need for another semicolon. It's just extra noise.

[yisar]

First of all, I strongly oppose semicolons and support non-semicolons, but I can also see a small number of semicolon enthusiasts.

Therefore, the optional semicolon is more acceptable.

The difficulty now is that there is no good plan to achieve it.

But I think in most cases, semicolons can be chosen, and semicolons can still be retained at certain special boundaries.

Like typescript, most of them can be omitted. For loops and so on, semicolons are still retained.

[tedhenry100]

@hlung I've been working in Swift for the past 2.5 years. Now learning Dart, I'm glad that semicolons are mandatory in Dart. As they say, there's no accounting for taste.

[kevmoo]

@munificent @leafpetersen @lrhn @eernstg – should be moved to language repo?

[munificent]

We can if you'd like.

[hlung]

@tedhenry100 well, if semicolon is matter of taste then it should not be mandatory. And it should be optional.

[naiveai]

I almost like this proposal, but I fear we'll end up with the dumb semicolon wars that are caused by JavaScript's ASI. Also, the arguments used by most people proposing this are mostly just "all modern languages don't have semicolons", which doesn't make much sense to me. Semicolon insertion takes a microsecond out of your day and it can easily be automated.

[munificent]

caused by JavaScript's ASI.

That's because JavaScript's ASI rules are bananas. Other languages with optional semicolons — Python, Ruby, Scala, Go, etc. — do not have dumb insertion rules and do not have wars over the use of semicolons.

[ditiem]

I am really surprised nowadays how many people like the idea of not typing semicolons.

Semicolon, to me, is a very important declaration from the programmer saying: 'I want this statement to end here'. After reading lots of code with semicolon, I found my brain can read faster by knowing how many line(s) have to be processed before passing to read the next statement.

It is not about ambiguity neither aesthetic. A line that does not end in a semicolon is like "unfinished job" to me. I believe (and unfortunately this cannot be demonstrated) the code ends up better structured when someone is forced to say when the statement finish. Otherwise the programmer tends to think too fast and make more mistakes.

[munificent]

I found my brain can read faster by knowing how many line(s)

The fact that you say "line" here, though, implies that it is actually the newline that is the signal your brain is relying on, not the semicolon.

[mockturtl]

the idea of not typing semicolons

At the risk of being pedantic, it isn't the typing as such. Readability suffers a little. What's genuinely unpleasant is hunting down mysterious, nearly-invisible errors, moving the cursor to end-of-line while fighting smart parentheses, and undoing saves because dartfmt newline-bombed me. :smile:

It feels like it would help for auto-completion tools to append semicolons more eagerly.

[Claus1]

It seems semicolons are very valuable for Dart team (7 years resisting developers desire).
But can they make at least optional semicolon before } ? It is very annoying getting errors (flutter) from the compiler that I have to insert ';' somewhere in )})} .

Example such code

onPressed: () {

                Navigator.push(context, MaterialPageRoute(builder: (context){
                  return Screen2();
                })
         );}), //it wants ; here, otherwise an error!

Very very annoying!

[munificent]

It seems semicolons are very valuable for Dart team (7 years resisting developers desire).

This isn't the right metaphor to describe the behavior. When you say "resist", that implies the Dart team has to spend effort to not make semicolons optional, but the opposite is the case. Semicolons are already mandatory in Dart, so to make them optional requires a significant amount of effort to change. The inertia is towards mandatory semicolons.

We (I in particular) have put quite a bit of work into trying to come up with a design for optional semicolons in Dart that plays nice with the rest of the language grammar, but unfortunately we haven't been able to come up with anything that harmonizes with the rest of the language. Other languages with optional semicolons tend to have simpler grammars with mandatory keywords for things like variable and member declarations. Dart's C/Java-derived grammar is a much larger challenge.

[rrousselGit]

This has been suggested before but it didn't receive answers:

What about moving that in the scope of _dartfmt_ instead?
We could keep the ; required, but have a tool that inserts them when obvious.

As a tool, it doesn't have to be perfect. It's fine if the tool is unable to add the ; in some situations.

[EugenePisotsky]

It's fine if the tool is unable to add the ; in some situations

sounds like it will be very confusing

[mit-mit]

@rrousselGit any tool -- whether it's a formatter or a compiler -- is going to have to be able to correctly parse it's input and determine where the implicit semicolons are. So I'm not sure the dartfmt approach is viable.

@Claus1 there are an endless number of things any language team can choose to work on; the tricky part is selecting the right ones. In this case we spent a significant amount of time investigating what it would take to add optional semicolons to an existing language that wan't designed for this initially (the design of Dart goes back more than a decade). It turned out it would realistically involve a larger number of breaking changes to make change core parts of our syntax. For more details, see the detailed write-up. Having uncovered that we decided that now wasn't the right time to do that; we are working hard to get NNDB completed. Also, please refrain from making personal comments (see https://dart.dev/code-of-conduct for details; personal statements such as "Dart team do not work hard enough" are not appropriate).

[rrousselGit]

@mit-mit dartfmt or the autocomplete.
The difference with a compiler is that the compiler has to be perfect and maintained over time.
Whereas dartfmt/autocomplete could stick to the simple scenarios, and potentially be reverted if too difficult to maintain.

And since it requires no language modification, it could start as an experimental fork of _dart_style_ without committing to anything.

[mit-mit]

@rrousselGit my main concern wasn't cost of implementation. It was ensuring the feature has a reasonable and predictable user experience. I don't think it's feasible, but maybe @munificent has thoughts on it?

[ds84182]

I have a stopgap solution for this. I don't really agree with optional semicolons, but I think dartfmt could help out in this area.

I have an editor shortcut that invokes dartfmt, and many people have "Format on save" enabled in their editors. The issue I sometimes hit, however, is that I miss a semicolon, so the format fails.

Instead of the language gaining optional semicolons (or, losing semicolons... we aren't really gaining much here!), could dartfmt instead gain automatic semicolon placement? I think either side can agree that this would be a good compromise, and would allow us to further evaluate our decisions. But for implementation work, that is ultimately up to @munificent.

[feinstein]

That's literally what @rrousselGit suggested 6 posts before yours.

[ds84182]

@feinstein I'm sorry, I didn't read that comment. I'll just remove mine.

[munificent]

What about moving that in the scope of dartfmt instead? We could keep the ; required, but have a tool that inserts them when obvious.

I don't think that's what most users want. If their expectation is informed by other languages, then they want to not have to think about semicolons at all — they don't want to have to write them, read them, eliminate them, etc. I don't think you can have "half-optional semicolons" and have a good user experience. No rug at all is better than a rug with a bunch of lumps in it for people to trip over.

[rrousselGit]

If their expectation is informed by other languages, then they want to not have to think about semicolons at all

There's a very good example of the opposite though: Javascript with Prettier

It's a very popular tool that does the same thing as dartfmt, but also adds semicolons. And it has a very good user experience.

[munificent]

JavaScript isn't a good reference for anything to do with semicolons because the specific rules JavaScript uses for semicolon insertion are terrible. All of the practices JavaScript programmers have adopted around semicolons are derived from that fundamental fact. Other languages have sane rules and saner practices. :)

[rrousselGit]

JavaScript isn't a good reference

This isn't about Javascript, but Prettier though.
Why would dartfmt necessarily have a bad UX by generating semicolons?

Do you have a concrete example where this would be _worse_ than what we currently have?

[EugenePisotsky]

@rrousselGit What is the point of comparing your solution to what we currently have instead of comparing it to the proposed solution in this topic?

As a user, I would like to have the option not to think about semicolons and not to see them in my code at all, and I wouldn't like to rely on tools that add them somewhere instead of me, but somewhere they don't, what makes things even more complicated. I don't understand what's the problem with completely optional semicolons. If someone really needs them so much, better to leave it for linter.

[munificent]

This isn't about Javascript, but Prettier though.

Prettier's choice to generate semicolons is a choice made in the context of the language it's generating semicolons for. Sure a watering can's just a tool, but it's not a tool that makes sense if what you've got is a cactus.

Do you have a concrete example where this would be worse than what we currently have?

I don't think you can do good usability analysis and tool design by seeking out single motivating examples for or against a certain approach. In this case, someone would have to actually design a semicolon insertion scheme — which in turn means designing the semicolon-less language that dartfmt would accept. Without a proposal for that, I don't see how you'd be able to evaluate it.

[asidt]

My 2 cents: let's keep semicolons, as taking them away doesn't really improve anything, and introduce a level of complexity which is useless by many degrees. Look at these examples with kotlin:

[EugenePisotsky]

@asidt those examples are advantages IMO. I wouldn't like to work with such code :)
I never experienced any problems related to semicolons programming on Kotlin.

[asidt]

@EugenePisotsky I also 'never experienced any problems related to semicolons programming on Kotlin', but now that I'm aware of that design choice, I fear it. It can be very misleading especially when coming from a Java background. So far I tested Swift handles it like a Java dev would expect , and Go lang doesn't have issues given is strictly formatted. Also, when coding I don't really want to think about 'splitting lines if the resulting two lines are also grammatically valid on their own'.

[hlung]

I think you are missing the point. Those complexity you see in your examples are coming from those languages “allowing” statements to be interpreted across lines, not from lack of semi colons. Those are hard to read by itself. We can in fact BOTH disallow interpreting code across lines AND having no semicolons.

On 20 Feb 2020, at 18:42, Alessio Salvadorini [e-mail] wrote:


My 2 cents: let's keep semicolons, as taking them away doesn't really improve anything, and introduce a level of complexity which is useless by many degrees. Look at these examples with kotlin:

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[charafau]

It would be nice to be able to remove them, but I think it would be more beneficial to focus on not nullables and then pattern matching, new collections etc because that's what would make development easier

[Voxar]

In many cases the compiler can be certain that a semicolon is missing, perhaps they can be optional in those cases at least until the syntax for the ambiguous cases can be sorted out?

If the compiler for any technical reason is not able to decipher the meaning of a statement without the extra delimiter then it's a requirement due an ambiguous language. If a compiler blatantly produces an obnoxious "Error: Expected ';' after this" message then it's just an unnecessary obstacle.

[lrhn]

In many cases the compiler can be certain that a semicolon is missing,

It can't, really. It can be sure that something is missing, and that inserting a semicolon is at least locally valid. I get the "Expected ';'` error in many situations where the error is something else, and I'd prefer the compiler did not try to ignore that.

[Hixie]

I never experienced any problems related to semicolons programming on Kotlin.

// valid
fun main() {
  { println("hello ") }()
  println("world")
} 

// compiler error
fun main() {
  println("hello")
  { println("world ") }()
} 

[matpag]

// valid
fun main() {
  { println("hello ") }()
  println("world")
} 

// compiler error
fun main() {
  println("hello")
  { println("world ") }()
} 

@Hixie What you posted here is not "real code" to me and I never seen something similar in any project I navigated nor someone complaining about not being able to write something similar.
But if you do it anyway, the compiler is smart enough to tell you how to fix that:

_Click on the image if you see it blurred_

Swift and Kotlin developers work everyday without semicolons madness and I just want to make sure that the point against adding optional semicolon is not related to something like "programming languages without semicolons have strange behaviours and developers don't know how to handle them" because that's not true in the real world and probably everybody who tried programming languages without semicolons are struggling using Dart and finding them back.

I would prefer an honest answer similar to: "Ok, we heard you but currently we don't have time to develop this feature because we want to prioritize other things", than finding arguments against it.

[Hixie]

I had that code in my project, I got confused by it, and the tooling didn't help me. I'm glad that you have a better experience, but that doesn't invalidate mine.

[bichikim]

It is a waste of resources to keep using semicolons.
If you plan to continue using the semicolons, why not just build the UI in assembly language? :)

[tatumizer]

It is a waste of resources to keep using semicolons.

If you are so short of resources, you have a much bigger problem than semicolons :-)

[asidt]

@matpag not to say, but check this out:

https://twitter.com/intelligibabble/status/1261040196897759234?s=20

that's a Google engineer fixing a bug because of the lack of semicolons, in a real life everyday code. The problem is that removing the semicolons forces the compiler to apply some rules to decide where one line ends; such rules can create ambiguous cases where the code doesn't do what developers would expect. This forces the developers to be well aware of such rules. I honestly and personally don't want to go to the compiler level and get to know such compiler's rules while I'm coding.

[matpag]

@matpag not to say, but check this out:

https://twitter.com/intelligibabble/status/1261040196897759234?s=20

that's a Google engineer fixing a bug because of the lack of semicolons, in a real life everyday code. The problem is that removing the semicolons forces the compiler to apply some rules to decide where one line ends; such rules can create ambiguous cases where the code doesn't do what developers would expect. This forces the developers to be well aware of such rules. I honestly and personally don't want to go to the compiler level and get to know such compiler's rules while I'm coding.

I don't think the problem is the missing semicolon.
The code in the tweet is equivalent to this:

...
is Foo -> {
    booleanCondition1
    booleanCondition2
}
...

In Kotlin the last statement is considered the return value, in this case the compiler should be smart enough to see that the booleanCondition1 value is not used anywhere and probably it's not your intention to just have it around.

I've tested on IntelliJ and there are no warnings, this is a compiler bug to me.

By the way, there is no perfect language/compiler and this is an edge-case which is not worth the 300-600 semicolons I type every day (and probably the Kotlin language designers arrived at the same conclusion).

[asidt]

@matpag IMHO the problem is the missing semicolon.

cond1 cond2

in kotlin prompts an error, but:

cond2

doesn't prompt any error because they are considered two statements which are perfectly fine; as you say, then the intrinsic return is applied on the last line. But the first line can't be considered a compiler bug, like you suggest, because to have an unassigned statement is perfectly fine from the compiler point of view. Think about a _showDialog()_ method which returns a boolean, the compiler can't complain because you haven't assigned its returned value, like:

showDialog()
doSomething()

Another example (definitely a bad practice, but still possible) would be a method which is called because of its side effects, and that returns something.
I politely disagree with you on the fact that my example is an edge case (the bug was fixed in real life, and also is quite a nasty bug to fix because when you read the code, you won't spot it easily); and even more about the fact that you can save 300-600 chars every day, as our job is not that you type 8 hours a day at constant full speed, you and me we also need to stop and think and design and reason, so 600 chars extra are nothing compared to the real burden of having nasty bugs because of language side effects. I agree no language is perfect, but I still want to make my point that removing semicolons is not worth the hassle of introducing such ambiguity about where the next line starts, and how lines are interpreted; me personally, is the very last thing I want to think about when I code.

[matpag]

You are right, from the compiler point of view is probably impossible to distinguish between a method call or an unused condition, so it's not a bug but something which can't be really fixed at all.

On the other side, I still consider this an edge case (and probably there are a lot more), on which we should not focus too much because for every feature there is always a drawback somewhere.

I just want to point out that the vast majority of "modern" programming languages which people love have been created without semicolons, Kotlin and Swift on top.
Do you think all the language designers behind them are out of their mind and want developers to suffer on subtle bugs? I don't think so, I think they evaluated the pros and the cons and came to the same conclusion, that using semicolons is useless 99% of the time.

[feinstein]

If typing semicolons is too annoying for someone, where's a tip: use a shortcut to do it automatically for you.

In IntelliJ IDEA Ctrl+Shift+Enter will "complete the current sentence", which for usual statements means to add a ; and go to the next line (it shouldn't go to the next line, but it does because of the Dart language server, it's a bug IMO).

So basically, instead of typing Enter with your right hand as you want, just type Enter with your right hand, while holding Ctrl+Shift with your left hand.

[RinOrz]

Not only the convenience of not having to type, but also the simplicity of reading, these are the benefits of the optional semicolon

[marcelgarus]

I'm completely on board with this issue being low-priority in the foreseeable future. I just want to point out that optional semicolons could also pave the way for even cooler syntactic sugar.

One example that comes to mind is Kotlin-style trailing lambdas that look just like regular control-flow structures.
Quick summary: If you have a method/function that takes another function as its last parameter, you're allowed to write the parameter _outside of the parameter list parenthesis_ and omit the parenthesis if they're empty (because of ambiguity reasons, in Dart, this should probably also be restricted to no-parameter lambdas / single-parameter lambdas with an implicit it parameter).
This would allow for code where you can kind of define your own control flow structures:

var randomNumbers = List.generate(8) {
  return Random().nextInt(100)
}

setState {
  _counter++
}

scheduleMicrotask {
  print('hello')
}

someFuture.then { print('Done: $it') }

repeat(7) {
  print('hello')
}

loop {
  print('blub')
}

var evenAgedNames = users
  .where { it.age.isEven }
  .map { it.name }

Now, I'm sure trailing lambdas alone don't justify messing with the syntax that much, but if there are more similar examples where the omittance of semicolons enables other language features that would otherwise be not possible or really ugly, it may make sense to think about implementing this feature for more than just directly visible aesthetic reasons.

[munificent]

I'm a big fan of trailing-lambda block argument syntax. I've designed a couple of hobby languages that have them.

That being said, Dart's existing grammar—independent of whether semicolons are optional or not—makes that very hard. Dart supports local functions and function declarations have no keyword to distinguish them. So:

foo(bar) {
}

Would ambiguously be either:

• Declare a local function foo that takes a single parameter named bar with type dynamic.
• Call the function foo passing the value of bar and an empty lambda.

[Ppang0405]

Any news?