Comments (25)
This comment was originally written by [email protected]
No no, keep the semicolons. It's like removing punctuation from litterature because it's noise. It helps with readability.
from sdk.
This comment was originally written by [email protected]
I'm fairly certain that most programmers who work with those languages (Go, JS) on a daily basis are aware of the "pitfalls" of ASI. I personally don't see these as pitfalls, since the grammar is quite clear and unambiguous about why "return\n foo" does what it does-- and if you acknowledge that a newline is a line ending like a semicolon is, it should really not be surprising at all. But I suppose this is ultimately what is up for debate.
That said, I don't see this as a reason in itself to be against ASI. It's important to realize that while forced semi colons are "familiar to many programmers", many programmers (I would say an extremely large population in this context, since we're primarily including the JS community here) are also very much familiar with ASI and optional semi colons. They aren't a new concept, and they are used in many languages-- JS and Go were named, but there are other languages that implement this in varying capacities too, like Scala, Ruby, Smalltalk. I'm not sure these other programmers appreciate being shunned in favor of treating the C*/Java users like first class citizens here, that seems to be what is happening.
Finally, I just want to say that I don't think we need to argue readability of programs with optional semicolons. If you've spent any amount of time writing programs in a language with optional semicolons, you likely understand why this is such an important point for many of the users coming from those languages. The reduction of semicolon noise is extremely significant, especially in a scripted world where lines are typically shorter than they are long. It's unfortunate to have to talk in terms of aesthetic choice when adopting a language, but aesthetics remains a reality in adoption, and I'd bet most newcomers from ASI-supporting languages would see this as quite a hurdle to proper adoption and acceptance of Dart as the future of the web. You're effectively telling all these JS programmers that the way they've been coding for years was outright wrong, and they are sitting there scratching their heads, because their code worked just fine-- and looked cleaner, too.
from sdk.
Very sad that this was closed. After having been working with Swift and Kotlin a few years, I don't see the need for semicolons at all. They just add noise. Typescript and many other modern langs don't require them. The code looks way cleaner and easier to read without.
from sdk.
@i-schuetz, to follow this topic today you need to look in the right place: dart-lang/language#69.
from sdk.
Is there any chance this will be reopened? Semicolons make Dart awful in comparison to languages like Scala or Kotlin.
from sdk.
This comment was originally written by [email protected]
@#c1 not to remove, just to make them optional.
Code is a literature too. But it has different punctuation, it's called indentation. All developers do use indentation, even when it has no meaning in the language.
Do you think that this code is unreadable? http://jashkenas.github.com/coffee-script/documentation/docs/optparse.html
I think it's beautiful.
from sdk.
This comment was originally written by [email protected]
I'd also like to express my opinion that semicolons should be kept, if only for syntax errors handling and recovery. Significant whitespaces are just bad idea for a lot of people.
from sdk.
This comment was originally written by [email protected]
What changes would you propose to the grammar (https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/language/grammar/Dart.g) that would make semicolons optional? I suspect you will find more hacks are required to make the grammar unambiguous.
Personally, having semicolons is far less painful that having semantic whitespace, as in python. The semicolon marks a clear end to the reader (and to compilers/IDEs as well, which gives much better error recovery), and the flip side of leaving it off is you wind up having to do ugly things like adding an unnecessary pair of parens and putting one on the previous line when you need to span multiple lines. Long nested blocks are also problematic to line up with only indentation level to go by.
from sdk.
This comment was originally written by [email protected]
Relying on white-spaces to parse code - no thanks. The readability improvement is too big to disregard, because you know - sometimes you aren't working on your 24" monitor.
from sdk.
This comment was originally written by [email protected]
Go has optional semicolons without the headaches of significant whitespace. They're handled by the lexer. Presumably, Dart could do something similar. I agree that making semicolons optional is a readability improvement. For those who want explicit semicolons, they can still add them.
http://golang.org/doc/effective_go.html#semicolons
http://groups.google.com/group/golang-nuts/browse_thread/thread/5ee32b588d10f2e9
from sdk.
This comment was originally written by [email protected]
Automated semicolon insertion, whether in Go or JS, has its own problems. In JS:
return
long expression
doesn't return what you think. In Go:
if condition
{
stmts
}
doesn't do what you think either.
My personal feeling is if you want to make semicolons optional and avoid these problems, you have to change the grammar. However, it isn't clear you aren't getting something worse than the syntax common to languages familiar to many programmers.
from sdk.
This comment was originally written by [email protected]
FWIW, I would even be willing to compromise and suggest using the Python-style "" line suffix to unambiguously denote that a statement was continuing to the next line, if it was the only way to get a consensus on ridding the world of all those unnecessary semicolons... but I am probably in the minority on that kind of a direction.
from sdk.
This comment was originally written by [email protected]
I second this proposal. ; should be optional along with {} for blocks
from sdk.
This comment was originally written by [email protected]
On one hand, I do think semicolons are line noise and should be optional. On the other hand, both significant whitepsace and optional syntax are two features abhorred by some. For example, I can take optional semicolons, but I wouldn't want parens or braces to be optional because the former is ugly and the later is error-prone. I don't recall having ran into non-brutally-obvious bugs due to the optional semicolons in Javascript.
from sdk.
This comment was originally written by [email protected]
Google is well positioned to add some data to this discussion: crawl a sample of JavaScript files in the wild and analyze what percentage of real world functions are affected by JavaScript ASI bugs. ASI might cause problems for programmers, but until we know the magnitude it's hard to make a sound decision
from sdk.
This comment was originally written by [email protected]
Added Area-Language, Triaged labels.
from sdk.
This comment was originally written by [email protected]
How do you propose executing all the world's Javascript and seeing if it has ASI bugs? That sounds like the halting problem to me, aside from the issue of knowing what the intended behavior was.
from sdk.
This comment was originally written by [email protected]
True, we can't definitively spot ASI bugs, but we could recognize common patterns that are likely to be incorrect. For example, in a large sample of JavaScript, what percentage of return statements are of the form "return\nlong_expression"? How often are semicolons omitted before a line that starts with an open paren? How often before a line that starts with an open bracket? Those are three of the most commonly mentioned problems with JavaScript's ASI rule. If one had a rough estimate of their prevalence, one could make a more informed design decision.
Another useful metric might be, what percentage of JavaScript lines trigger the ASI rule at all? JavaScript developers can omit semicolons today if they want to. It would be useful to know how often they do it. If 95% of existing JS code uses explicit semicolons, there's no reason to support ASI in Dart. If the number were 50%, one might conclude differently.
Without data of this sort, either decision is arbitrary. Of course, semicolons won't decide Dart's fate, so it may be a moot discussion anyway :-)
from sdk.
Removed Type-Defect label.
Added Type-Enhancement label.
from sdk.
Set owner to @gbracha.
from sdk.
This comment was originally written by [email protected]
Keep the semicolons. Let me indent how I want. Let me put braces where I want.
from sdk.
This comment was originally written by [email protected]
Please keep semicolons. I know very long lines probably indicate I should restructure the code, but they do happen.
That's why I don't buy above coffee-script example and significant white space has been a bad idea ever since Makefile - don't go there.
return this.getClassName() + '(' + this.sw.getLat() + ',' + this.sw.getLng() + ',' + this.ne.getLat() + ','
+ this.ne.getLng() + ':' + this.sw.getSrs().getName() + ')';
from sdk.
Say NAY to semicolon!
Any explanation from contributors why in 2019 do you still need a semicolon?
from sdk.
Ok then.... i do hate the need to put semicolons in the end of the line too, so, if the Dart team wants to keep this semicolon, at least make the linter auto add it and the auto complete as well. Done. We won't need to bother about it again...
Make it optional would be much better, but auto add is almost good...
from sdk.
Any explanation from contributors why in 2019 do you still need a semicolon?
This feature is now discussed in dart-lang/language#69 and dart-lang/language#72. Please post any new comments in those threads.
The short answer is: Because the Dart grammar, with it's C/Java roots, adjacent identifiers in declarations and overloaded operator meanings, makes it hard to omit semicolons without making the end of statements ambiguous and unparsable to the compiler (and/or to the user, depending on how the necessary heuristics are tweaked).
from sdk.
Related Issues (20)
- "Error: The macro can only be applied to enums or enum values." - What interface to use instead? HOT 1
- Failures on [ CLI ] Fix issue where 'dart build' would fail to find the 'dart' when run from PATH
- Analyzer response to LSP requests extremely slow w/ high latency reported HOT 9
- [breaking change] On Windows refer to special `null` file as '\\?\nul' rather than 'nul'. HOT 7
- LSP Server fails to initialize if an inlayHints request is sent before the client responds to workspace/configuration HOT 23
- DateTime implementation on linux, dates before year 2020 return incorrect timezone HOT 8
- Inconsistent behavior of beginToken for some analyzer AST nodes with doc comments HOT 1
- [dart2js] Incorrect inference for override with default of widened type
- [ddc] Incorrect defaulting of named arguments with certain names
- DDC async function stepping improvements HOT 1
- When performing floating-point calculations, precision may be lost在进行浮点数计算时精度会丢失 HOT 7
- [typed_data] Add `Float16List` + [vm/ffi] Add `Float16` HOT 15
- Code completion contains many duplicated items (for extensions?)
- dart2wasm miscompilation around dynamic switch targets HOT 1
- Unexpected TypeError from js_interop only in DDC HOT 1
- Maybe ZoneSpecification's fork behavior is broken? HOT 3
- Attempt to start the daemon using the IPv6 loopback if the machine does not have 127.0.0.1 loopback IP address
- [ddc] Can we migrate all calls of `getReifiedType()` to a member of the dart:rti library?
- Analyzer Feedback from IntelliJAnalysis server has terminated HOT 2
- Have any examples show how to export methods from dart to JavaScript? HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sdk.