Implicit Semicolon?

Topics: C# Language Design
Sep 15, 2014 at 1:24 AM
What would it take to have implicit semicolons in C#
So that this
var csharpModel = semanticModel as CSharpSemanticModel
is equivalent to this
var csharpModel = semanticModel as CSharpSemanticModel;
Source
Sep 15, 2014 at 8:04 AM
Edited Sep 15, 2014 at 8:05 AM
It would change the meaning of some code and make some existing code not compile.

This would not compile:
var x = something
    as SomeType;
If in C# 6, you can use expressions other than assignment, call, increment, decrement and new object expressions as statements, this will compile and behave differently:
var a = (A(42, 42, 42) - B(42, 42, 42))
   - (C(42, 42, 42));
Dropping the third subtraction on the floor.

As well as this:
class X { int A; }

int A;

var x = new X()
{ A = 42 };
In this case, you would go from assigning x.A to assigning the local variable A. Effectively, it would mean introducing significant whitespace in C#.

The worst problem would probably be readability with LINQ and builders.
Sep 15, 2014 at 1:32 PM
There are sound arguments in favor of using semicolons as statement delimiters, or of using newlines for that purpose. When using newlines as statement delimiters, my preference would be to require markers at the starts of lines indicating either 'first line of multi-line statement' or 'subsequent line of multi-line statement', though editors would need to be aware of that so as to sensibly handle following indent. I really dislike optional delimiters; even if there are supposedly-well-defined cases where delimiters are or are not required, I think it's much better to have things behave consistently than identify cases where things can safely work differently.
Sep 15, 2014 at 2:41 PM
Almost anyway this is implemented would be an extremely dangerous breaking change to the language wouldn't it?
Sep 18, 2014 at 4:59 PM
AdamSpeight2008 wrote:
What would it take to have implicit semicolons in C#
So that this
var csharpModel = semanticModel as CSharpSemanticModel
is equivalent to this
var csharpModel = semanticModel as CSharpSemanticModel;
Source
This is considered to be one of the absolute worst aspects of the JavaScript language. Why on Earth would any other language want to adopt it?
Sep 19, 2014 at 12:19 AM
Halo_Four wrote:
AdamSpeight2008 wrote:
What would it take to have implicit semicolons in C#
So that this
var csharpModel = semanticModel as CSharpSemanticModel
is equivalent to this
var csharpModel = semanticModel as CSharpSemanticModel;
Source
This is considered to be one of the absolute worst aspects of the JavaScript language. Why on Earth would any other language want to adopt it?
TSQL has optional semicolons on almost every statement and Microsoft has announced that in the near future they won't be optional anymore.

Even considering it for C# is a huge step back.
Sep 19, 2014 at 1:19 AM
Halo_Four wrote:
This is considered to be one of the absolute worst aspects of the JavaScript language. Why on Earth would any other language want to adopt it?
I agree that the statement separators should not be optional unless a language requires that multi-line statements be marked with line continuation characters (I personally would prefer the latter to the former). I don't think that design decision would make my top twenty list of either "what were they thinking!?" decisions nor my list of decisions that most severely impaired the language's usefulness or expressiveness. Just about every aspect of the language which is changed by "use strict"; represents a far more serious problem, though at least the aspects which are fixed by "use strict"; can be pretty well mitigated by adding that to each code file. Still, there are countless other things that can't be fixed, such as the combination of loosy-goosy variable typing and dynamic operator overloading which makes "1"+"2" equal "12", but "1"-"2" equal -1, or the fact that attempting to assign an undefined property creates a new definition.

If a language is going to use C-style syntax for compound statements, it should use C-style syntax for statement separators, but JavaScript's failure to do so is relatively harmless. Personally, I prefer a line-oriented approach, with separators being considered essentially synonymous with newlines, but I don't have particularly strong feelings on the issue. Certainly none that would make me call the optional statement terminators as the worst aspect of JavaScript.
Sep 19, 2014 at 1:45 AM
supercat wrote:
Halo_Four wrote:
This is considered to be one of the absolute worst aspects of the JavaScript language. Why on Earth would any other language want to adopt it?
I agree that the statement separators should not be optional unless a language requires that multi-line statements be marked with line continuation characters (I personally would prefer the latter to the former). I don't think that design decision would make my top twenty list of either "what were they thinking!?" decisions nor my list of decisions that most severely impaired the language's usefulness or expressiveness. Just about every aspect of the language which is changed by "use strict"; represents a far more serious problem, though at least the aspects which are fixed by "use strict"; can be pretty well mitigated by adding that to each code file. Still, there are countless other things that can't be fixed, such as the combination of loosy-goosy variable typing and dynamic operator overloading which makes "1"+"2" equal "12", but "1"-"2" equal -1, or the fact that attempting to assign an undefined property creates a new definition.

If a language is going to use C-style syntax for compound statements, it should use C-style syntax for statement separators, but JavaScript's failure to do so is relatively harmless. Personally, I prefer a line-oriented approach, with separators being considered essentially synonymous with newlines, but I don't have particularly strong feelings on the issue. Certainly none that would make me call the optional statement terminators as the worst aspect of JavaScript.
That feature is #3 on the list of "Awful Parts" in Douglas Crockford's book and I would consider that an authority on the subject. If a lot of time is spent on the subject then perhaps situations of ambiguity could be avoided. Otherwise you get the garbage of what the following does in JavaScript:
// What am I actually returning?
return
{
    foo: "bar"
};
I don't mean to imply that there aren't also many, many other things in JavaScript which aren't completely messed up. You could probably take a torch to 80% of the language spec and it would be better off for it.
Sep 19, 2014 at 1:56 AM
Halo_Four wrote:
That feature is #3 on the list of "Awful Parts" in Douglas Crockford's book and I would consider that an authority on the subject. If a lot of time is spent on the subject then perhaps situations of ambiguity could be avoided. Otherwise you get the garbage of what the following does in JavaScript:
What's the real problem there--the fact that semicolons are optional, or the overloading of braces for compound statements and object definitions? Looking at that list, I don't think the items are listed in order of severity. Having parseInt("031")==25 is far more apt to cause real-world bugs; likewise the behavior of global variables and scopes.
Sep 19, 2014 at 7:58 AM
There's no direct connection between a language being dreadful and its having semicolons or not. I agree with what's been said about JavaScript, but there are more languages than C# and JavaScript. For example, Swift, Ruby and Python all work well without semicolons because it's been part of their language design from the beginning. I think it's just plain hard to retrofit a hybrid mode on an existing language because of all the small syntax choices and nuances informed by the initial decision.
Sep 19, 2014 at 10:33 AM
Edited Sep 19, 2014 at 10:34 AM
supercat wrote:
If a language is going to use C-style syntax for compound statements, it should use C-style syntax for statement separators, but JavaScript's failure to do so is relatively harmless.
The semicolon in C# is not a statement separator: it is a statement terminator and as such an essential part of the actual statement. Don't confuse the two, they're semantically different.
Sep 19, 2014 at 11:26 AM
BachratyGergely wrote:
supercat wrote:
If a language is going to use C-style syntax for compound statements, it should use C-style syntax for statement separators, but JavaScript's failure to do so is relatively harmless.
The semicolon in C# is not a statement separator: it is a statement terminator and as such an essential part of the actual statement. Don't confuse the two, they're semantically different.
Well said!
Sep 19, 2014 at 11:28 AM
supercat wrote:
Halo_Four wrote:
This is considered to be one of the absolute worst aspects of the JavaScript language. Why on Earth would any other language want to adopt it?
I agree that the statement separators should not be optional unless a language requires that multi-line statements be marked with line continuation characters (I personally would prefer the latter to the former).
That was called Visual Basic and it's changing with the addition of implicit line continuations when the compiler is able to identify the next line as being part of the current statement.
Sep 19, 2014 at 11:56 AM
PauloMorgado wrote:
supercat wrote:
Halo_Four wrote:
This is considered to be one of the absolute worst aspects of the JavaScript language. Why on Earth would any other language want to adopt it?
I agree that the statement separators should not be optional unless a language requires that multi-line statements be marked with line continuation characters (I personally would prefer the latter to the former).
That was called Visual Basic and it's changing with the addition of implicit line continuations when the compiler is able to identify the next line as being part of the current statement.
Indeed, although since it's not possible with the language to be able to eliminate all ambiguities without explicit line continuation there are still plenty of circumstances in which they are required. Probably the worst thing a language specification could have is the word "sometimes", particularly when followed by a numerous and unmemorable list of caveats. Fortunately most VB.NET devs would be using VS which goes out of its way to keep them from messing that up.
Sep 19, 2014 at 1:35 PM
Halo_Four wrote:
Indeed, although since it's not possible with the language to be able to eliminate all ambiguities without explicit line continuation there are still plenty of circumstances in which they are required. Probably the worst thing a language specification could have is the word "sometimes", particularly when followed by a numerous and unmemorable list of caveats. Fortunately most VB.NET devs would be using VS which goes out of its way to keep them from messing that up.
VS does a pretty good job there, though I would have preferred to have line continuations mandatory but just introduce a better syntax for it; parsing is a teensy weensy smidgin easier with continuations marked at the end of the previous line rather than the start of the next, but I think legibility would have been much better if the first line of each multi-line statement had to be marked at the start with one character (leftmost column) and subsequent lines with another; VS could have easily made it so that hitting return in the middle of an "incomplete" line would mark the start of it and the newly-inserted blank line.

With regard to separators vs terminators, I meant to use the term "delimiters", which I think is applicable in either case.