Optional end of line semi-colons

[mythz]

This has been brought up a few times so I thought it would be a good idea to have this written down somewhere so we can measure demand for it.

So devs who want this feature can star the issue here:

http://code.google.com/p/dart/issues/detail?id=4461

The case for optional semi colons is obvious: 

Mandatory semi colons just adds un-necessary line-noise making the code uglier and less fun.

It would be nice if Dart followed all the modern C-like languages i.e. Scala, Go, Kotlin and not require end-of-line semi colons. 

It's actually rare to require them considering most functional, scheme-like, scripting & dynamic langs avoid them as well. I understand Dart is meant to appeal to C# / Java devs, but they would still be able to optionally add end of lines semi-colon if it makes them more comfortable - whilst the rest of us can write prettier code :)

Normally I wouldn't suggest this, but since even modern C-like languages are able to get by without them, I don't expect them to be too disruptive to implement.

[Bernhard Pichler]

I'm coming from C++ and C# and i'm very used to my beloved semi-colons. I just looked at my code and thought about how it would look without the semi colons on the end of some lines. Maybe if i use it for some time i get used to it too, but today i would really feel bad and i think the code would be less readable for me too. I know that many other languages works fine without the semi colons, but i think the semi colon makes the code more structured.

It would be interesting to have some stats about how many programmers like the semi colon. I wouldn't be surprised if the majority (>95% ??) of all Dart programmers are pro semi colon. 

[Ladislav Thon]

I've been thinking about optional semicolons a lot in the past and ended up with a simple decision: I'd love to get rid of them, but so far, I didn't see any approach that I would like. AFAIK, most languages nowadays use a simple approach of automatically inserting semicolons in the lexer on well defined places... which, in most languages, makes this simple code wrong:

var result = query(collection)

  .filter(...)

  .map(...)

  .take(1)

Here, semicolons are usually inserted at the and of each line, which is exactly what I don't want. And heck, I really don't to write dots at line ends. This exact case is so popular that, IIRC, Ruby 1.9 made a special case for it. Umm... not a fan, really.

The other possible approach requires parser cooperating with lexer, which is a lot more complex, and the rules to understand are more complex too.

And the last approach, designing the grammar so that there are no semicolons necessary, is probably impossible in C-style languages.

So for the time being, I want mandatory semicolons.

LT

P.S.: the issue is a duplicate of http://dartbug.com/34.

[Matthew Butler]

I'm also pro semicolon, in addition to above, it would also cause issues with cascades, closures, and the => shortcut.

Matt

[Cassio Tavares]

Yes for semi colons.

Making them optional is a mistake in my opinion. Some will use it and some note even in the same file, class, method....

And it's working now perfectly.

[Hamcha]

I'm pro semi-colon, it's actually pretty automatic for me to put semicolons, even in languages where they aren't used (which leads me to errors every now and then..).
Personally I find them useful in a syntactical way: They delimit where an instruction end and where the next begin, really useful if you were to minimize code or do something like this:
object.x = 10; object.y = 20; (which I find prettier to write on the same line, being fashinated by lua's cross-assignment)

Also, I think that it shouldn't be made "optional", just leave them or take them out, I feel like having them optional goes against the language philosophy itself (but that's all IMO).

PS: I'm new to mailing lists, sorry if I did something wrong :(

> --
> Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
>
>

[Rémi Forax]

On 08/12/2012 06:16 PM, Ladislav Thon wrote:
> I've been thinking about optional semicolons a lot in the past and
> ended up with a simple decision: I'd love to get rid of them, but so
> far, I didn't see any approach that I would like. AFAIK, most
> languages nowadays use a simple approach of automatically inserting
> semicolons in the lexer on well defined places... which, in most
> languages, makes this simple code wrong:
>
> var result = query(collection)
> .filter(...)
> .map(...)
> .take(1)
>
> Here, semicolons are usually inserted at the and of each line, which
> is exactly what I don't want. And heck, I really don't to write dots
> at line ends. This exact case is so popular that, IIRC, Ruby 1.9 made
> a special case for it. Umm... not a fan, really.
>
> The other possible approach requires parser cooperating with lexer,
> which is a lot more complex, and the rules to understand are more
> complex too.

No, it's easy.
For each state of the grammar, the parser need to disable the lexer
automaton that will generate an error
if the token is recognized by the lexer. (see
http://weblogs.java.net/blog/forax/archive/paper.pdf)
So now, the lexer will fail fast saying that no automaton match at the
end of an instruction,
in that case, the lexer can ask the parser the current state and see if
there is a transition
use semicolon that doesn't lead to an error. If it's true, the semicolon
is inserted.
Basically, you only insert semicolon when otherwise a syntax error
should be raised.

>
> And the last approach, designing the grammar so that there are no
> semicolons necessary, is probably impossible in C-style languages.
>
> So for the time being, I want mandatory semicolons.
>
> LT
>
> P.S.: the issue is a duplicate of http://dartbug.com/34.

> --
> Consider asking HOWTO questions at Stack Overflow:
> http://stackoverflow.com/tags/dart
>
>

R�mi

[Ladislav Thon]

No, it's easy.
For each state of the grammar, the parser need to disable the lexer automaton that will generate an error
if the token is recognized by the lexer. (see http://weblogs.java.net/blog/forax/archive/paper.pdf)
So now, the lexer will fail fast saying that no automaton match at the end of an instruction,
in that case, the lexer can ask the parser the current state and see if there is a transition
use semicolon that doesn't lead to an error. If it's true, the semicolon is inserted.

Well, I'd say that this is a lot more complex :-) Especially if you have the parser and lexer written by hand (which is the case in all Dart implementations), and if you don't invoke the lexer incrementally from the parser, but you first tokenize the whole input and then invoke the parser later (which is the case at least in Dart VM). Possibly much later -- functions/methods in Dart VM are parsed on the first use. This would have to be solved purely in the parser. Not that it can't be done...

I'd expect that this solution would be much better than some pure-lexer ASI... but I'd also guess that it would complicate error handling a bit. (Possibly a lot, I have no clue.)

LT

[Rémi Forax]

On 08/12/2012 08:37 PM, Ladislav Thon wrote:
>
> No, it's easy.
> For each state of the grammar, the parser need to disable the
> lexer automaton that will generate an error
> if the token is recognized by the lexer. (see
> http://weblogs.java.net/blog/forax/archive/paper.pdf)
> So now, the lexer will fail fast saying that no automaton match at
> the end of an instruction,
> in that case, the lexer can ask the parser the current state and
> see if there is a transition
> use semicolon that doesn't lead to an error. If it's true, the
> semicolon is inserted.
>
>

> Well, I'd say that this /is/ a lot more complex :-) Especially if you

> have the parser and lexer written by hand (which is the case in all
> Dart implementations), and if you don't invoke the lexer incrementally
> from the parser, but you first tokenize the whole input and then
> invoke the parser later (which is the case at least in Dart VM).
> Possibly much later -- functions/methods in Dart VM are parsed on the
> first use. This would have to be solved purely in the parser. Not that
> it can't be done...

A parser can be separated in two levels, level one just use the input
terminal to know in which state of the automata you are (you also need a
stack of states), this level has enough information to add semicolon
automatically and it doesn't require to have propagate attributes or
build an AST which are things that are done in the second level. In
DartVM, even if you only do the tokenize pass as you say, you still have
to run a sligh grammar on top in order to match parenthesis, find the
start of a method, of a class, etc. This is exactly what level one
provide you.

Now, you're right that using a parser written by hand for that is not easy.

And by the way, the parser used in the Java editor is generated using
ANTLR and the parser used by Dart2JS seems to be the ANTLR version
ported in Dart but maybe i'm wrong.

>
> I'd expect that this solution would be much better than some
> pure-lexer ASI... but I'd also guess that it would complicate error
> handling a bit. (Possibly a lot, I have no clue.)

The lexer has not enough information, you need to know if the current
token will raise an error and if you can insert a semicolon just before
this token.

>
> LT

[Seth Ladd]

Thanks for the feedback, this is indeed a common request. The original issue request was http://code.google.com/p/dart/issues/detail?id=34  However, it was reviewed by the team and was decided to keep the semicolons.

Here's what Lars said (in http://code.google.com/p/dart/issues/detail?id=34#c60) in response:

We have decided not to support optional semicolons for the following reasons:
- White space should not have semantic impact.
  In JavaScript the worst problem related to this is around return.
    return
      1
  This will return undefined which is completely broken.
- Dart programs will be become more consistent and therefore easier to read. 

--

[mythz]

Sounds like support is pretty heavily in favour of pro semi-colons - happy to go with the majority on this.

In this case my new +1 vote goes to fading out semi-colons and braces in the Dart IDE :)

http://code.google.com/p/dart/issues/detail?id=3417 

[Lasse R.H. Nielsen]

On Sun, Aug 12, 2012 at 8:22 PM, Rémi Forax <fo...@univ-mlv.fr> wrote:
> Basically, you only insert semicolon when otherwise a syntax error should be
> raised.

That's what JavaScript did. I don't consider that a success, since it
makes it too difficult to predict what happens. A classic examples of
a problem is:

x = y
(a + b).foo()

The rule in JavaScript/ECMAScript is deceivingly simple: If a token
after a newline cannot continue the current expression/statement, and
a semicolon could, then a semicolon is automatically inserted. Combine
that with some grammar productions that disallow newlines (e.g.,
between ++/-- and the operand or after return/throw/break/continue)
then you have a system that is ripe with opportunity for surprise.

Those exceptions are annoying, but probably necessary to make omitting
semicolons evenh remotely viable, since otherwise reasonable code
like:
if (foo) return
bar = 42
would always be a problem.

This has lead some people recommending a semicolon-style where you put
the semicolon at the beginning of lines that might otherwise continue
the next one (e.g.
http://inimino.org/~inimino/blog/javascript_semicolons ).

I don't think a solution based on inserting semicolons only at syntax
errors is viable (and I don't think JavaScript ASI is successful at
allowing semicolons to be omitted). The complexity introduced is
simply too great, compared to the simple rule of always using
semicolons.
/L
--
Lasse R.H. Nielsen
l...@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K -
Denmark - CVR nr. 28 86 69 84

[Rémi Forax]

Ok,
the other possible semantics is to insert a semicolon instead of a newline
if it creates a valid statement without taking care of the following tokens.
At least, this rule is far easier to understand that the ASI rules.

R�mi

On 08/13/2012 11:20 AM, Lasse R.H. Nielsen wrote:

[Eric Leese]

One case where that rule might cause trouble:

var func(var arg)

{

  // ...

This could be a declaration of func that does not assign anything to it, followed by a block, or the definition of a function.  Options include:  1. Change the way variables are annotated as having a function type, 2. Teach everyone to move the opening brace to the end of the preceding line, or 3. Make an exception to the rule for opening braces -- don't insert the semicolon before the opening brace unless there is a blank line in between.

On Monday, August 13, 2012 3:08:01 PM UTC-7, Rémi Forax wrote:

Ok,
the other possible semantics is to insert a semicolon instead of a newline
if it creates a valid statement without taking care of the following tokens.
At least, this rule is far easier to understand that the ASI rules.

R�mi

On 08/13/2012 11:20 AM, Lasse R.H. Nielsen wrote:

[Lasse R.H. Nielsen]

On Tue, Aug 14, 2012 at 12:08 AM, Rémi Forax <fo...@univ-mlv.fr> wrote:
> Ok,
> the other possible semantics is to insert a semicolon instead of a newline
> if it creates a valid statement without taking care of the following tokens.
> At least, this rule is far easier to understand that the ASI rules.

That restricts how you can break a line.
Some prefer
var x = longthing &&
otherlongthing;
but others prefer
var x = longthing
&& otherlongthing;
This suggestion would break the latter example.

C-like syntax isn't built for omitting semicolons, and through it's
long history it has developed different styles, and I believe any
attempt at automatically inserting semicolons will break at least one
style. Either by inserting too many or inserting too few if you start
omitting semicolons.

I'm not against languages without semicolons. I just don't think it's
feasible to convert the existing C-like syntax to support it without
breaking too much. A fresh syntax that is actually designed for it
would work, but that's not what Dart is trying to do.

I'd love to be proven wrong, of course, but anything resembling
JavaScript's ASI won't convince me :)

[Rémi Forax]

On 08/14/2012 05:33 AM, Eric Leese wrote:
> One case where that rule might cause trouble:
>
> var func(var arg)
> {
> // ...
>
> This could be a declaration of func that does not assign anything to
> it, followed by a block, or the definition of a function. Options
> include: 1. Change the way variables are annotated as having a
> function type, 2. Teach everyone to move the opening brace to the end
> of the preceding line, or 3. Make an exception to the rule for opening
> braces -- don't insert the semicolon before the opening brace unless
> there is a blank line in between.
>

No, there is no problem here because this is not a statement but a
declaration.
You only want to insert semicolon in order to finish a statement.

R�mi

>
> On Monday, August 13, 2012 3:08:01 PM UTC-7, R�mi Forax wrote:
>
> Ok,
> the other possible semantics is to insert a semicolon instead of a
> newline
> if it creates a valid statement without taking care of the
> following tokens.
> At least, this rule is far easier to understand that the ASI rules.
>

> R�mi

>
> On 08/13/2012 11:20 AM, Lasse R.H. Nielsen wrote:

> <http://inimino.org/%7Einimino/blog/javascript_semicolons> ).

> >
> > I don't think a solution based on inserting semicolons only at
> syntax
> > errors is viable (and I don't think JavaScript ASI is successful at
> > allowing semicolons to be omitted). The complexity introduced is
> > simply too great, compared to the simple rule of always using
> > semicolons.
> > /L
>

[Rémi Forax]

On 08/14/2012 10:03 AM, Lasse R.H. Nielsen wrote:

> On Tue, Aug 14, 2012 at 12:08 AM, R�mi Forax <fo...@univ-mlv.fr> wrote:
>> Ok,
>> the other possible semantics is to insert a semicolon instead of a newline
>> if it creates a valid statement without taking care of the following tokens.
>> At least, this rule is far easier to understand that the ASI rules.
> That restricts how you can break a line.
> Some prefer
> var x = longthing &&
> otherlongthing;
> but others prefer
> var x = longthing
> && otherlongthing;
> This suggestion would break the latter example.
>
> C-like syntax isn't built for omitting semicolons, and through it's
> long history it has developed different styles, and I believe any
> attempt at automatically inserting semicolons will break at least one
> style. Either by inserting too many or inserting too few if you start
> omitting semicolons.

I'm fine with that.
I even find that this is a good property because it enforces a common style.
This is something I like in python, you have only one style.

You can think that I'm a fanatic but I force all my students to write
their code the same way,
so I'm able to spot bugs just by looking over their shoulders, which is
something vital when you have 40 students in a lab.

>
> I'm not against languages without semicolons. I just don't think it's
> feasible to convert the existing C-like syntax to support it without
> breaking too much. A fresh syntax that is actually designed for it
> would work, but that's not what Dart is trying to do.
>
> I'd love to be proven wrong, of course, but anything resembling
> JavaScript's ASI won't convince me :)
>
> /L

R�mi

[KDawg]

Lack of an end-of-statement terminator is a horrible idea. Case in point, consider Kotlin:

var x = 1 + 1 + 1
println(x)

results in 3, whereas

var x = 1 + 1
+ 1
println(x)

results in 2.

the lack of an end-of-statement terminator creates ambiguous code. Making them optional only makes the situation worse.

[rym...@gmail.com]

Uhh...that's not really ambiguous if you know that new lines are terminators. It's just getting used to it. 

--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups "Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Istvan Soos]

On Mon, Feb 26, 2018 at 4:15 PM, rym...@gmail.com <rym...@gmail.com> wrote:
> Uhh...that's not really ambiguous if you know that new lines are
> terminators. It's just getting used to it.

This is a religious topic, but we may have a place for a personal anecdote.

I've spent about 6 months working on a CoffeeScript codebase. I made
at least two line-ending mistakes over that time, which slipped though
the review and reached production. Not fun. It makes everyone's life
miserable to think about it, and it is much easier to typing that
extra `;` character (and overall saves time). I'd favor explicit over
implicit any time, because it served me over the years.

Cheers,
Istvan

[tatumizer-v0.2]

Maybe comma can be made optional as a separator of name-value pairs - both in constructors (for named parameters) and map literals.

This won't be as bug-prone IMO. And it can help to un-clutter object literals in flutter. Not sure it's a good idea though.

[Istvan Soos]

'We' ' do ' 'have' ' adjacent string literals:' 'Let\'s spot the error'.

[Ryan Gonzalez]

CoffeeScript is definitely more on the extreme end of "free syntax"
than most similar languages, though. In addition, in languages like
Dart that have things like status analysis, the analyzer could warn
with unused expressions.

FWIW I've also managed to make the same mistake in C++ when I try to
refactor something and split expressions incorrectly, but the compiler
will always warn you.

So stuff like this wouldn't be a problem:

var x = 1
+ 1 // warning: unused expression

> --
> For other discussions, see https://groups.google.com/a/dartlang.org/
>
> For HOWTO questions, visit http://stackoverflow.com/tags/dart
>
> To file a bug report or feature request, go to http://www.dartbug.com/new
> ---
> You received this message because you are subscribed to the Google Groups "Dart Misc" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.
>

[Rob Becker]

Hard pass on optional semicolons. Just no. One of the things that I love about Dart is that it is opinionated and has an awesome style guide and formatter. I don't want to go back to nitpicks on code reviews about whether you should or shouldn't use semi-colons (or tabs, or braces, or etc...)

[tatumizer-v0.2]

'We' ' do ' 'have' ' adjacent string literals:' 'Let\'s spot the error'. 

This must be rare. But you WILL spot the error easily in IDE b/c highlighting. And in case of named parameters, this counterexample doesn't apply.

The issue is more like - to what extent this feature can help, even if implemented. 

[Bob Nystrom]

On Mon, Feb 26, 2018 at 8:53 AM, Rob Becker <robrb...@gmail.com> wrote:

Hard pass on optional semicolons. Just no. One of the things that I love about Dart is that it is opinionated and has an awesome style guide and formatter. I don't want to go back to nitpicks on code reviews about whether you should or shouldn't use semi-colons (or tabs, or braces, or etc...)

If we were to move to optional semicolons like Go did, we would be just as strongly opinionated as we are today and push for an ecosystem where no one uses semicolons, and dartfmt gracefully formats your code without them.

This is exactly how the ecosystems for Python, Ruby, Go, Swift, Scala, Kotlin, and others work. In all of those languages, semicolons are allowed but optional, and you almost never see them in the wild.

(I'm not mentioning JS in that list because the specific semantics JS chose for semicolon insertion are so broken that it effectively kills the feature. I'd quit my job at Google before I shipped a semantics that bad for Dart.)

Cheers!

– bob

 

On Sunday, August 12, 2012 at 2:17:31 AM UTC-6, mythz wrote:

This has been brought up a few times so I thought it would be a good idea to have this written down somewhere so we can measure demand for it.

So devs who want this feature can star the issue here:

http://code.google.com/p/dart/issues/detail?id=4461

The case for optional semi colons is obvious: 

Mandatory semi colons just adds un-necessary line-noise making the code uglier and less fun.

It would be nice if Dart followed all the modern C-like languages i.e. Scala, Go, Kotlin and not require end-of-line semi colons. 

It's actually rare to require them considering most functional, scheme-like, scripting & dynamic langs avoid them as well. I understand Dart is meant to appeal to C# / Java devs, but they would still be able to optionally add end of lines semi-colon if it makes them more comfortable - whilst the rest of us can write prettier code :)

Normally I wouldn't suggest this, but since even modern C-like languages are able to get by without them, I don't expect them to be too disruptive to implement.

--

[Randal L. Schwartz]

>>>>> "Bob" == 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> writes:

Bob> (I'm not mentioning JS in that list because the specific semantics
Bob> JS chose for semicolon insertion are so broken that it effectively
Bob> kills the feature. I'd quit my job at Google before I shipped a
Bob> semantics that bad for Dart.)

And for which Brendan Eich has publicly apologized. :)

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/Dart consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

[Faried Nawaz]

KDawg <kevin...@gmail.com> writes:

> Lack of an end-of-statement terminator is a horrible idea. Case in point,
> consider Kotlin:
>
> var x = 1 + 1 + 1
> println(x)
>
> results in 3, whereas
>
> var x = 1 + 1
> + 1
> println(x)
>
> results in 2.

I think that's just bad style. This parses properly, in Kotlin, JS,
Ruby, and Go:

var x = 1 + 1 +
1
println(x)

It's not a lot of work to encode the rules for where semi-colons are
automatically inserted, or where they're needed. Go, for example, has
just two rules; see https://golang.org/ref/spec#Semicolons


Faried.

[Bob Nystrom]

On Mon, Feb 26, 2018 at 6:05 AM, Faried Nawaz <far...@gmail.com> wrote:

KDawg <kevin...@gmail.com> writes:

> Lack of an end-of-statement terminator is a horrible idea. Case in point,
> consider Kotlin:
>
> var x = 1 + 1 + 1
> println(x)
>
> results in 3, whereas
>
> var x = 1 + 1
> + 1
> println(x)
>
> results in 2.

I think that's just bad style.  This parses properly, in Kotlin, JS,
Ruby, and Go:

    var x = 1 + 1 +
    1
    println(x)

And, in particular, if you run dartfmt on the code, it will put the "+" at the end of the previous line.

Of course, any optional semicolon behavior we define needs to gracefully handle code that has not been formatted yet too (if for no other reason than to be a well-defined input to dartfmt), but our style guide and formatter already set up your newlines in a way that's quite friendly to significant newlines.

Cheers!

– bob

[Adrian Mercieca]

100% pro mandatory semi-colon.
Code is clearer, more well defined/structured with semi-colon.

[Tobe Osakwe]

I agree with Adrian.

> On Feb 26, 2018, at 11:24 PM, Adrian Mercieca <amer...@gmail.com> wrote:
>
> 100% pro mandatory semi-colon.
> Code is clearer, more well defined/structured with semi-colon.
>

[Kasper Peulen]

There may be a way to make everybody happy here.

Remove all semicolons, and have an option to see them in the editor (without them being really there).

I picture this similarly as how Flutter shows the end of a Widget by a comment that is not really there.

That being said, semicolons are just noise, they decrease readability, liking them is like a bad habit. In the beginning you crave it, but after a while life is actually easier when you quit.

Met vriendelijke groet, Kasper Peulen

[Danny Tuppeny]

If only everyone was as enthusiastic about removing nulls as removing semicolons! 😁

The idea of removing semicolons feels kinda weird to me, but I do wish there was less noise in my code so I reckon I'd get to used to it. Presumably the next step is removing braces and being whitespace-sensitive? No? :(

[Filipe Morgado]

On Tuesday, 27 February 2018 14:38:53 UTC, Danny Tuppeny wrote:

If only everyone was as enthusiastic about removing nulls as removing semicolons! 😁

THIS!!!

I favor optional semi-colons, although it would seem very weird at first.

But in the end, it's pretty insignificant, IMO.

It's mostly relevant to new-comers. They will either love it or hate it, depending on their background, but it all comes down to habits.

I'd rather see new features that are actually useful.

[Erik Ernst]

On Tue, Feb 27, 2018 at 3:31 PM, Kasper Peulen <kasper...@gmail.com> wrote:

There may be a way to make everybody happy here.

Remove all semicolons, and have an option to see them in the editor (without them being really there).

I picture this similarly as how Flutter shows the end of a Widget by a comment that is not really there.

That being said, semicolons are just noise, they decrease readability, liking them is like a bad habit. In the beginning you crave it, but after a while life is actually easier when you quit.

Here's one perspective which is rarely mentioned: `class A {}` is easy to parse because `class` is a reserved word, but when a class body contains a declaration like `set get(get) => set = 2 * get.get` then there's a need for more disambiguation, simply because a token like `get` can be a "keyword" that indicates "this declaration is a getter" and it can also be a name (here: the name of a setter, and the name of a formal parameter, and the name of a member of the actual argument).

The point is that if we make semicolons optional then the amount of ambiguity in the syntax of the language goes up, and then we need to be more conservative in the creation of new syntactic constructs (in order to be able to parse Dart programs at all).

Basically, the syntactic language design space gets smaller every time we make the language more ambiguous.

--

Erik Ernst  -  Google Danmark ApS

Skt Petri Passage 5, 2 sal, 1165 København K, Denmark

CVR no. 28866984

[Randal L. Schwartz]

>>>>> "Danny" == Danny Tuppeny <da...@tuppeny.com> writes:

Danny> The idea of removing semicolons feels kinda weird to me, but I do
Danny> wish there was less noise in my code so I reckon I'd get to used
Danny> to it. Presumably the next step is removing braces and being
Danny> whitespace-sensitive? No? :(

And then the "spaces vs tabs" battle will begin. :)

[Bob Nystrom]

On Tue, Feb 27, 2018 at 6:38 AM, Danny Tuppeny <da...@tuppeny.com> wrote:

If only everyone was as enthusiastic about removing nulls as removing semicolons! 😁

I think most people are more enthusiastic about removing nulls. :) But it's also a much more complex feature to ship.

 

Presumably the next step is removing braces and being whitespace-sensitive? No? :(

No, definitely not. I could write an essay about this but the short summary is that significant indentation works OK for Python but pushes you towards a statement-oriented mindset. This is why, for example, lambdas can only contain a single expression, not statements in Python. You can do significant indentation in an expression-oriented language — Haskell does — but it's weird and quirky.

Dart is not at all as statement-focused as Python. Idiomatic Dart code often contains lambdas (expressions) containing block bodies (statements) containing other lambdas (expressions) containing block bodies (statements). That kind of interleaving gets mega-weird if you try to use indentation for blocks.

Curly brace blocks work really well, I think. It's useful to have an explicit terminator for a region of code and "}" does that.

Cheers!

– bob

[Randal L. Schwartz]

>>>>> "Bob" == 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> writes:

Bob> Curly brace blocks work really well, I think. It's useful to have an
Bob> explicit terminator for a region of code and "}" does that.

I like it because a text editor can easily go "out block" or "end of
block" or "beginning of block". It's why I always do my Perl regex as
m{foo}... because my editor is happy at that.

[Danny Tuppeny]

On Tue, 27 Feb 2018 at 17:38 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:

If only everyone was as enthusiastic about removing nulls as removing semicolons! 😁

I think most people are more enthusiastic about removing nulls. :) But it's also a much more complex feature to ship.

Yeah, it wasn't a moan that it's not here yet (for once!) but I've often been in discussions where devs didn't understand the benefits of removing null ("we have null-aware operators, just use them, k?") and it makes me kinda sad (I guess I'm kinda at conveying them)!

 

Presumably the next step is removing braces and being whitespace-sensitive? No? :(

No, definitely not. I could write an essay about this but the short summary is that significant indentation works OK for Python but pushes you towards a statement-oriented mindset. This is why, for example, lambdas can only contain a single expression, not statements in Python. You can do significant indentation in an expression-oriented language — Haskell does — but it's weird and quirky.

Dart is not at all as statement-focused as Python. Idiomatic Dart code often contains lambdas (expressions) containing block bodies (statements) containing other lambdas (expressions) containing block bodies (statements). That kind of interleaving gets mega-weird if you try to use indentation for blocks.

Curly brace blocks work really well, I think. It's useful to have an explicit terminator for a region of code and "}" does that.

Heh, my comment was meant as a joke, but I appreciate the extra info :-)

[Tom M]

Dart gets semicolon insertion and Go uses pub.

[Jan Mostert]

Death to null :-D
Kotlin and Ceylon's null works lovely, just mark stuff as Type? if it's nullable, otherwise Type if it's non-nullable.
Would be great to have null safety in Dart as well, currently we're getting so used to it in Kotlin that some devs 

forget to do null checks in Dart when they have to work on the frontend again.

Python's lack of curly braces drove me nuts when i was still using Python.

In Python 2, often bugs would creep in because somebody used spaces to indent and somebody used tabs to indent and some tab would slip through 

causing a statement to appear in a certain block, but actually be outside that block

+1 for no semicolons or at least making them optional

Coming from a Java background, it's normal to want to type semi-colons, it almost happen by muscle memory 

and it would be annoying if it caused compiler errors when you added semi-colons accidentally.

Having worked in Kotlin for the last two years, i wouldn't say i miss semi-colons,

when i accidentally add a semi-colon (after switching back from Dart to Kotlin), Kotlin doesn't complain either, 

it just suggest that the semi-colon is not needed.

Either way, semi-colons do not bother me much, nulls on the other hand is a different story.

--