-
Notifications
You must be signed in to change notification settings - Fork 205
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
Optional Semicolons #69
Comments
I love the idea of optional semicolons 👍 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. |
Updated the description. This will be covered in much more detail in the actual proposal. |
Related SDK issues: dart-lang/sdk#34, dart-lang/sdk#30347 |
Maybe there could be additional syntax to avoid ambiguity, only in cases where it could lead to ambiguities, something like:
Or
|
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 |
I agree, this should be a feature |
Optional semicolons is the first step to fuck up the code style if you are not only one developer on the project. |
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 |
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. |
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:
It can be written as:
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. |
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 |
Two things i want to mention that would make code Dart likely fun
|
I did a bunch more investigation of optional semicolons after writing the "Terminating Tokens" proposal. I wrote up my thoughts on the experience here. |
I started learning Dart this week and was quite surprised to know that it requires semicolons. |
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. |
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? |
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. |
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. |
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. |
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. |
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. |
@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. |
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. |
That's good data to have, but is somewhat confounded:
But, in general, yes, optional semicolons aren't a clear huge win. |
That would be great, I love this feature when developing in TypeScript. It felt so natural I didn't even notice it until I came back to Dart, and found myself having to manually type semicolons again. |
Here are my 2 cents: coming here with a 30+ year background of developing embedded C and, occasionally C++. Then on Android Java, obviously, and then Kotlin. Therefore, to get this out of the way: I know my semicolons. And yes, omitting them in Kotlin felt strange at first but that quickly wore of in favor of a much cleaner visual appeal of the the code. While I do get the argument of how much work this is behind the scenes for a seemingly non-functional change, adopting it would make coding in Dart more fun for most existing and new users. The arguments in the OP are not baseless. Also, adopting good things from other languages is a sign of strength. Using this a distinguishing language property seems like a very weak argument to me. I am aware that words like "fun" and "clean" are highly subjective, but I hope you understand what I am aiming for here. |
A little "controversial" opinion: Typescript's default style uses semicolons; see examples in official docs, such as https://www.typescriptlang.org/docs/handbook/intro.html C# uses semicolons. (Typescript is heavily inspired by C# and created by C# language designers.) If those two are not "modern languages, " I'd argue nothing else is. When I see semicolon-less TS it's usually coming from the folks with recent JS background (and not very quality background, to put it mildly). I.e., I'd go as far as to say that folks still writing JS in the modern day (instead of TS) are not followers of very high standards, IMHO. I love Python the way it is, and I'd never add semicolons to it. But I'd leave TS, C#, or Dart as is. P.S.: Along with the bunch of downvotes I'll receive, I hope to at least get some portion of upvotes from folks who don't think semicolons are "outdated". |
Of all arguments, the one associating the lack of semicolons with bad code quality "because of JS" is probably the lamest. Seriously? We're better because we have semicolons? Regarding C# and other more modern languages: do not underestimate that once new languages wanted to be adopted (not unlike your quest for upvotes, @Troyx21 😜). I'm pretty sure that in some cases people tried to keep at least some of the C/C++ feel just by keeping the semicolons. Anyway, I'm here only because I stumbled over this checking out Flutter after a long period of work in Kotlin and I felt Flutter/Dart subjectively(!) to be a step back. I guess that this argument is the deciding one and I can understand its proponents from a technical POV. |
@xrad Keep in mind that the "no-semicolons" style has been around for at least as long as the semicolons style. It is not a new feature, let alone a "modern" feature. It's just another style, and like every style, the choice is inherently subjective and each one comes and goes in fads. |
Of course @Abion47, I have repeatedly acknowledged that much of this discussion is rather subjective. I understand that and certainly this makes it so controversial. However, most of the traditional holders of public popularity in the recent 10-20 years DO use semicolons with JS being a rather isolated outlier. From that perspective a lack of semicolons feels subjectively more modern to some of us. Also worth noting is that back in the day of lex and yacc and even before, the semicolon was a cheap and reliable way to provide decent parser error recovery (well at least until C++ came along, lol.) Modern parsing technology should not be as reliant on explicit statement separators. But be that as it may. Personally I probably won't even be doing much Dart coding anytime soon, but reading this thread I felt an urge to throw in my 2 cents. I am aware that most of this theoretical and the established devs have no personal desire or technical reason for a change like this for the reasons given. |
And this is precisely what I'm referring to. Just because it feels more modern doesn't mean that it is. The only reason it "feels" modern is that there have been multiple high-profile languages that have come out recently that eschew semicolons or leave them optional. Just like how a couple of decades ago, it felt like all the big languages coming out were mandating semicolons. That's why I say it's more than just subjective, it's a fad. It's a needle on a gauge that switches direction with as much regularity and predictability as the tides. No-semicolon languages are "in" right now, but give it a decade or two and semicolon languages will likely be "in" again. This isn't to say that there aren't legitimate reasons to prefer a no-semicolon language. It's just that chasing the no-semicolon fad with the excuse that it "feels modern" is not just disingenuous, it's an exercise in futility.
It has absolutely nothing to do with parsing technology. As I said, languages have been able to support having no semicolons for as long as there have been programming languages. Speaking historically, semicolons are the more modern feature. The choice between which approach to use has nothing to do with how technically difficult it is to implement from the start* and has everything to do with the philosophy behind the designers of the language. (*: "From the start" being the key phrase, here. Now that Dart has been out for years, changing the approach now is a major undertaking and is the single biggest reason why this feature will likely not be implemented any time soon, if ever.) |
Semicolons absolutely (also) had to with parsing, namely providing a cheap way for syntax error recovery. Maybe one needs have written a parser from scratch to better appreciate this point. WRT that and some other historical implications I can also recommend this Quora post. Given that semicolons are strictly unnecessary and that language development is generally pointing in the direction of cleanliness and concisiveness, I'd still argue that using semicolons are more a thing of the past than thay are of the future. I doubt they'll stick in the long run and I doubt your notion that they are simply an aspect of current fashion. But again, I never denied this is a subjective matter. Let's agree to disagree. :-) |
I have written a parser, thanks. Incidentally, I've written a parser both for a semicolon language and a no-semicolon language. The difference in technical complexity? Not that high. Or to put it more accurately, the difference in complexity of the language syntaxes themselves far outstripped the complexity added by a semicolon or lack thereof. If you want to go to other sources, I'll cite the one you provided:
The semicolon in C was a design choice, not a technical necessity. And C wasn't the first one, either. It built on the idea that earlier languages like ALGOL pioneered which used the semicolon as an optional statement separator as opposed to a mandatory statement terminator. Yes, semicolons (or any explicit statement terminator) make some aspects of parsing easier. However, it is far from necessary seeing as languages like BASIC and COBOL, famously no-semicolon languages, predate C's popularization of the feature, and other languages like Haskell, which are "old" but are newer than C, also managed to do fine without "modern parsing technology". The "technology" to have an expressive language without resorting to a semicolon has been around for ages. It's a philosophical decision far more than it is a technical decision.
The problem with making a claim like that is that there is no consensus whatsoever as to what "cleanliness and concisiveness" means in terms of language grammar. For example, some argue that (almost) pure functional languages are the pinnacle of clean code, but I've yet to see F# and Elixir sweep the entire industry. So yes, I agree that language development is moving toward clean and concise code, and the industry as a whole will be better for it. But what that actually means in practice, as well as whether that trend includes or excises semicolons, depends entirely on who you ask.
Except again, you're basing this opinion on current popularity trends, not on historical evidence. I'd argue that you're blinkering yourself by your own personal experience. You've gone from C to Java, and then spent a lot of time with Kotlin. This has given you the impression of "progress" away from semicolon languages to a no-semicolon language. And yes, languages like Python, Go, and Swift have similarly popularized the no-semicolon trend. But on the other side, you have rising languages like Typescript that, while they don't require semicolons, include them in the official style guide. You also have new popular languages like Rust and Carbon (pending) that do use semicolons, not to mention Dart itself (which we can now call a popular-ish language). And hell, you could use semicolons in Python if you really wanted to. It's easy to get the impression that semicolons are on the way out if we are looking at the bandwagon-y languages. But looking at the industry at large, there is no indication whatsoever of that being a real trend. The only trends that actually matter are the languages that have stood the test of time, seeing rising regular use over time, and those trends indicate that semicolon languages and no-semicolon languages are co-existing happily and will continue to do so long into the foreseeable future. As such, design your language to have a semicolon or don't. It really doesn't matter much either way in the end. |
You continue to dodge the specific point wrt parsing issues which I will now make for the 3rd time: I was only referring to semicolons of providing a cheap (computation-wise) way to recover from syntax errors. That specific point can also be found in the source I cited, which you conveniently omitted in your citattion:
Actually I started my dev carrier deep in the 80s with semicolon-less BASIC (actually the colon could be used to separate statments but that the norm AFAIR.) and a ton of Assembly on many different architectures. When studying we did a lot of coding in Pascal which has its very own take on semicolons. So I would respectfully dismiss /your/ interpretation of /my/ sense for a modern language. I tried to make it clear before: I care less about this than it may seem as I will probably not working with Dart a lot anyway, but I found the OP interesting enough to engage and contribute to this discussion. |
Semicolons do not make parsing arbitrary grammars easier. The Dart grammar, based on the C-family of syntax, relies on semicolons to determine when a statement ends. foo.bar()
[1].baz should be one statement or two. We could try to use newlines, but sometimes Dart does continue statements over multiple lines. We could try to introduce some heuristic, based on the tokens occurring on either side of the line break, to make some of the line breaks be statement terminators, and others not. Our programmers would then have to memorize those heuristics. We could try to use indentiation, and it could probably be made to work (and we could remove In any case, it would have to be a much different language. If we wanted a language without statement terminators/separators, well ... I wouldn't start from here. 😉 |
Are you sure about that?
Did you skip this part when reading my response?
Or this one? I didn't dodge the point, I disputed its validity. There's a difference. Yes, a lot of languages that followed C included semicolon terminators. However, I argue that that was due to those languages banking on C's popularity, or from the developers of those languages being C developers themselves and that influencing their decision, being the key factor, not the technical benefit of the semicolon itself. The evidence of that argument is the plethora of expressive languages both before and since C's release that did so without semicolons. It is also entirely tangential to the argument whether Dart itself should have semicolons. |
The real ;tl;dr on why optional semi-colons will likely never land in Dart is here. Not exactly a glowing endorsement, but the current maintainers can't turn back the clock and design Dart without its (generously speaking) quirks. |
I think it's pretty clear by now that realistically dart will have semicolons for a long time. So if it's bothering you so much, and since you are all very capable programmers, why not just make an IDE plugin that adds a Sure it won't be right many times, but better than nothing for everyone that seems so unhappy about this. (IntelliJ is sopposed to do this with |
@feinstein I imagine the stumbling block is that the logic that determines when a semicolon should be automatically inserted would suffer from the same issues of ambiguity that @lrhn mentioned, making such a tool deceptively difficult to make in practice. It would also end up being a large source of frustration for people who like to use line breaks to organize their statements such as the following: final argb = (a & 0xFF) << 24
+ (r & 0xFF) << 16
+ (g & 0xFF) << 8
+ (b & 0xFF); I don't know about you, but if my IDE entered a semicolon whenever I pressed enter while writing this code, I wouldn't be using that IDE much longer. |
I am not saying IDEs should do this automatically, I am saying you can turn this on/off if you want to, to feel better 70% of the time, and really pissed 30% of the time. Just another choice on the table, that's all. |
It is talking about moving type declaration to the right like in Kotlin and Python. I think the current type declaration is more readable than the other way around. I am happy with semicolons and the current type declaration place. |
Imagine having to write semicolons for a language created in 2011... 😫 😞 |
Since Dart is likely to require semicolons for a while longer, I think it's useful to adapt to that reality as best we can. While the details are different, JavaScript and TypeScript do face a somewhat similar issue, as supporting optional semicolons is a challenge for the future evolution of ECMAScript, thus some dev teams and projects may configure Prettier and other automatic formatters to enforce mandatory semicolons as a precaution. In such cases, I expect the best option available for people who dislike the "visual clutter" of so many semicolons is to configure one's editor or IDE to minimize that impact. Such configuration is likely to be very similar for both Dart and JavaScript, thus I think it makes sense to include instructions for both languages together in one place so everyone can benefit. I created a discussion to this effect in the Deno project repo, since I personally hope Deno emerges as a "standard" runtime for JavaScript alongside Node. However editor and IDE configuration along these lines is shared by Deno and Node, JavaScript and TypeScript, and also Dart. So I'll link this here in case any Dart developers would like to add to that discussion. It doesn't really matter where the instructions live, so long as it's available to everyone, meaning any public discussion on GitHub will work, and I'd rather have it here than in some obscure comment on Reddit, or Stack Overflow, or whatever. How to dim semicolons in editor or IDE I added instructions for VS Code, for JavaScript and TypeScript as well as Dart. I'm going to leave it for others to document how to handle this for JetBrains, Neovim and other editors and IDEs, since I'm not familiar with those. In particular, Android Studio seems to be sort of a "default" tooling choice for Dart, so Dart devs are probably more familiar with JetBrains products. If someone wishes to add appropriate JetBrains instructions for Dart, JavaScript and TypeScript together, everybody wins. Thanks. |
Please check out rust, zig and carbon (to name a few). |
Could we have the same semantics from Groovy? I checked dozens of programming languages and Groovy is the only with types on the left and no semicolons. class User {
String name
}
user = new User()
user.name = "Dash"
println user.name The code above compiles and prints "Dash". |
I support the idea, just from a philosophical standpoint I support the idea of removing unnecessary syntax, deprecated features and the like from the language. So long as new ideas and features are well designed and well tested. Hard to add and easy to take away tech debt. Lest every language becomes C++ and no one wants that. |
@slyblood I think no one likes unnecessary syntax. In this case, |
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.
The text was updated successfully, but these errors were encountered: