Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Optional Semicolons #69

Open
mit-mit opened this issue Oct 31, 2018 · 182 comments
Open

Optional Semicolons #69

mit-mit opened this issue Oct 31, 2018 · 182 comments
Labels
request Requests to resolve a particular developer problem

Comments

@mit-mit
Copy link
Member

mit-mit commented Oct 31, 2018

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.

@mit-mit mit-mit added the request Requests to resolve a particular developer problem label Oct 31, 2018
@yjbanov
Copy link

yjbanov commented Oct 31, 2018

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.

@mit-mit
Copy link
Member Author

mit-mit commented Nov 1, 2018

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

@mit-mit mit-mit closed this as completed Nov 1, 2018
@mit-mit mit-mit reopened this Nov 1, 2018
@mit-mit
Copy link
Member Author

mit-mit commented Nov 1, 2018

Related SDK issues: dart-lang/sdk#34, dart-lang/sdk#30347

@feinstein
Copy link

feinstein commented Nov 16, 2018

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

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

I agree, this should be a feature

@korgara
Copy link

korgara commented Jan 12, 2019

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

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

munificent commented Jan 14, 2019

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

Buerkut commented Jan 29, 2019

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

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

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 .

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

@munificent
Copy link
Member

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

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

@ivnsch
Copy link

ivnsch commented Mar 17, 2019

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.

@ivnsch
Copy link

ivnsch commented Mar 17, 2019

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?

@leafpetersen
Copy link
Member

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

yisar commented Mar 20, 2019

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

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

Hixie commented Mar 21, 2019

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.

@ivnsch
Copy link

ivnsch commented Mar 21, 2019

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

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

Hixie commented Mar 21, 2019

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

munificent commented Mar 21, 2019

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.

@dJani97
Copy link

dJani97 commented Aug 30, 2022

I just want some eslint + prettier stuff that can add semicolon automatically.....

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.

@xrad
Copy link

xrad commented Oct 29, 2022

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.

@Troyx21
Copy link

Troyx21 commented Nov 3, 2022

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

@xrad
Copy link

xrad commented Nov 3, 2022

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.

@Abion47
Copy link

Abion47 commented Nov 4, 2022

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

@xrad
Copy link

xrad commented Nov 4, 2022

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.

@Abion47
Copy link

Abion47 commented Nov 4, 2022

@xrad

From that perspective a lack of semicolons feels subjectively more modern to some of us.

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.

Modern parsing technology should not be as reliant on explicit statement separators.

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

@xrad
Copy link

xrad commented Nov 4, 2022

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

@Abion47
Copy link

Abion47 commented Nov 4, 2022

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.

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:

Actually, they are not necessary. Python, one of the most “beginner-friendly” languages in the world, is not dependent on semicolons.

When we design a language, we want something compilers can easily work with, when considering that anyone can write any sort of code that fits the specification of the language.

For languages like BASIC, new-lines are enough as end-of-command thingy. For languages like C, a design choice was made to have an explicit symbol to split statements from each other, and the semicolon became that symbol.

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.

...language development is generally pointing in the direction of cleanliness and concisiveness...

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.

...I'd still argue that using semicolons are more a thing of the past than thay are of the future.

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.

@xrad
Copy link

xrad commented Nov 4, 2022

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:

From a perspective of parsing, it’s useful to have something dependable to signal the end of a statement—if the parser encounters an error bad enough that it can’t productively do further processing on the current statement, it’ll often be written to ignore input until it gets to the next statement, to avoid spewing lots of meaningless error messages.

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.

@lrhn
Copy link
Member

lrhn commented Nov 4, 2022

Semicolons do not make parsing arbitrary grammars easier.
Some grammars are perfectly easy to parse without using semicolons.
Lisp S-expressions is an extreme example, but arguably it just uses a different terminating token.
Other language grammars work well without any statement terminator character, for example because they have unambiguous statement starters, or uses indents to recognize statement/expression termination, or their grammars are otherwise unambiguous in when something stops and something else starts.

The Dart grammar, based on the C-family of syntax, relies on semicolons to determine when a statement ends.
Simply removing semicolons from the current Dart grammar would make the grammar highly ambiguous.
We'd need some other way to determine whether

 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 {...} blocks too!), but it would make dart format much less useful, because you need to have proper indentation before it can even parse the program. Error recovery would likely suffer too. Some might even say that the result would be worse than what we started with.

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

@Abion47
Copy link

Abion47 commented Nov 4, 2022

You continue to dodge the specific point wrt parsing issues which I will now make for the 3rd time

Are you sure about that?

Yes, semicolons (or any explicit statement terminator) make some aspects of parsing easier. However, it is far from necessary...

Did you skip this part when reading my response?

...the difference in complexity of the language syntaxes themselves far outstripped the complexity added by a semicolon or lack thereof.

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.

@godenji
Copy link

godenji commented Nov 4, 2022

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.

@feinstein
Copy link

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 ; on each Enter key inside a {} block?

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 Ctrl + Enter but it's very buggy in dart)

@Abion47
Copy link

Abion47 commented Nov 4, 2022

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

@feinstein
Copy link

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.

@deadsoul44
Copy link

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.

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.

@berteodosio
Copy link

Imagine having to write semicolons for a language created in 2011... 😫 😞

@Waldenesque
Copy link

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
denoland/deno#17621

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.

@tatumizer
Copy link

Please check out rust, zig and carbon (to name a few).

@dart-lang dart-lang deleted a comment from jeudryWepsys Jun 26, 2024
@Wdestroier
Copy link

Much of the difficulty of doing optional semicolons in Dart compared to other languages comes from a few parts of the language

C-style declaration syntax. We could require a keyword for declaring a variable like TypeScript, Kotlin, and Swift all do. Possibly even move types on the right.

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

@slyblood
Copy link

slyblood commented Nov 3, 2024

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.

@mateusfccp
Copy link
Contributor

@slyblood I think no one likes unnecessary syntax. In this case, ; is necessary (or, at least, very useful, to the point that removing it and replacing it with something else that works as well in the context of the current Dart is very hard).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
request Requests to resolve a particular developer problem
Projects
Status: Icebox
Development

No branches or pull requests