Make semicolon optional in C# vNext

[andrei-m-code]

Semicolon is a useless character and a long lasting legacy that has to go. Compiler can figure out if it's the end of statement on it's own.

Making semicolon optional will lead to better language efficiency. Programmers would be more focused on coding and less on the syntax itself. I've got a countless amount of missing semicolon compile time errors and I'm sure I'm not the only one - it wasted thousands of total developer hours to fix it.

Good references of languages that don’t need semicolons: F#, Kotlin, JavaScript. Why can’t it be done with C#?

Please make it optional in the next version.

[HaloFour]

Compiler can figure out if it's the end of statement on it's own.

In many cases it can't because the language was not designed to be whitespace sensitive in that way. The language could never fully eliminate semicolons meaning that developers then have to learn all the rules as to when they can be omitted. It also limits possible future evolution of the language. Big amount of work for no real benefit. Most languages have required syntactic structure and learning is a necessity. Whitespace sensitive languages are loaded with such gotchas that don't exist in C#.

[jnm2]

Duplicate of https://github.com/dotnet/csharplang/issues/496.

[HaloFour]

https://github.com/dotnet/roslyn/issues/5355

[ghost]

Absolutely not please, in no way does it "have to go". It should not take thousands of hours to fix missing semi-colons for anyone who understands imperative programming.

Semi-colons provide context that inform other developers of the statement, erasing punctuation from our languages does not improve them it makes them more confusing.

This is unilaterally a non-improvement, you go from fixing semi-colons (which are trivial) to fighting with white-space which can feel orders of magnitude more arbitrary and in doing so you remove control from the developer (which seems counter to the way C# is designed to operate).

With semi-colons your statement doesn't end until you say it does, without them you must constrict your usage of white space accordingly.

[andrei-m-code]

In many cases it can't because the language was not designed to be whitespace sensitive in that way

@HaloFour can you give me a few examples where it's not possible?

[andrei-m-code]

With semi-colons your statement doesn't end until you say it does, without them you must constrict your usage of white space accordingly.

Why do you think so? There are clear notions of end-of-statement like new variable introduction, or curly braces end or switch, do, if, for, foreach statements etc., with this you can put as many spaces and line-breaks between your LINQ calls as you want. Compiler can be smart enough to understand it. And you won't have to type this stupid ";" 200 times a day and get compiler error 2 times a week because you forgot it.

[svick]

@andrei-m-code JavaScript has a similar system, called "automatic semicolon insertion" As I understand it, it's considered to be a misfeature and a cause of "gotchas". You might want to look into that and consider how would you solve those issues.

As one example, consider this code:

M(() => {
    return
    f()
});

Is this the same as if the lambda contained return; f(); or return f();? Both can be valid, depending on what overloads M has.

[andrei-m-code]

@svick we are in a strongly-typed world. JavaScript is great but it indeed has many gotchas https://www.youtube.com/watch?v=ryJSRZzAvUs, pretty much like any other non-strongly-typed lang. In C# you can't declare a delegate like this without making a compiler know it's actual type.

[svick]

@andrei-m-code I can make the compiler choose between more than one type:

void M(Action action) {}
void M(Func<int> f) {}

int f() => 0;

…

M(() => {
    return;
    f();
});

M(() => {
    return
    f();
});

Both calls to M above compile fine.

Also, it seems you want to make syntax (where to insert a semicolon) depend on semantics (types). I don't think that would work, at least not without a significant rewrite of the compiler.

[ethanae]

@andrei-m-code I really don't understand your argument of removing semi-colons would increase language efficiency (what does that mean exactly?) and that requiring developers to use semi-colons decreases their ability to focus on feature coding. If you've spent 'thousands of total developer hours to fix it', the problem is manifest in people knowingly creating broken code or not knowing how to write code in the first place. Removing concise and deterministic syntax only makes things harder for developers on both sides (as @svick helpfully mentions).

[andrei-m-code]

@ethanae obviously I didn't spend that much time fixing it. But I'm sure total developer time to run a compiler and then seeing an error, going there and fixing it would be in thousands of hours for the period of .NET (and Java) existence.

How many statements or lines of code do you write a day? Of course you'd be more productive if you don't have to type ; again; again; again; again; and again;. There are really not many cases when it's problematic to figure out end of statement by a compiler. @svick just presented one of those, where maybe compiler should ask developer to explicitly define delegate type. But even the case with Action is a bad practice - don't leave unreachable code! I'd give Func case here a priority to resolve this conflict. Method overloads with generics, extension methods and implicit type casting is a pretty big mess, so I'd say we have some gotchas in the syntax already.

I just see that .NET community is a bit rusty to radical innovative improvements. Just take a look at other more modern programming languages. Kotlin is a great example. This language is very similar to C# in many ways, except language creators really focused on efficiency and removing useless stuff from syntax, and it worked out great! No punctuation, lots of great language feature - a lot smarter compiler. Just take a look outside of your comfy .NET box.

[CyrusNajmabadi]

I just see that .NET community is a bit rusty to radical innovative improvements

The LDM has spent a lot of time thinking about thsi over the years. As mentioned initially, it's definitely feasible to do this sort of thing in a language. However, it's much easier when you're considering it from the start (like Kotlin could do) rather than trying to bolt it on 15+ years into the life of a language.

There are many concerns in this area (which i've attempted to outline in several posts about thsi topic over the years).

except language creators really focused on efficiency and removing useless stuff from syntax, and it worked out great!

As pointed out, this can actually be a hindrance to efficiency. People can and do run into subtle problems here where their code means something different than what they intended. I've run into it myself in these other languages.

[HaloFour]

I just see that .NET community is a bit rusty to radical innovative improvements. Just take a look at other more modern programming languages. Kotlin is a great example.

Kotlin is an example of a language designed from day one to be parsed like this. Same with Scala. Same with Javascript (in the most idiotic way). Same with F#. Same with Swift.

The problem isn't some obsession with semicolons. It's the problem of trying to retrofit the syntactic structures of one language onto another when that language is 18 years old and 7 versions in.

See the proposals for adding braces to python for an example of the inverse. It doesn't make sense in either direction.

[DavidArno]

I just see that .NET community is a bit rusty to radical innovative improvements

Making semi colons optional is fiddling whilst Rome burns. For serious radical improvements, how about we make reference types non-null by default? How about we add many many functional style features to the language? How about we allow default method implementations in interfaces? Now they would be radical innovations ... oh wait, they are all planned for C# 8. Hmm, not sure “rusty” is the best term therefore. “Open to genuinely radical improvements" seems to fit better.

[andrei-m-code]

The problem isn't some obsession with semicolons. It's the problem of trying to retrofit the syntactic structures of one language onto another when that language is 18 years old and 7 versions in.

@HaloFour Strongly disagree! C# has been evolving by taking best practices and features from other languages for it's whole life and it will be. Do you think where Linq came from or ?. or extension methods or async/await. It all was successfully (scratched out)stolen taken from more modern languages.

@davkean I think we do better lately.

[orthoxerox]

@andrei-m-code you should learn the history of LINQ and async/await before making such claims.

[HaloFour]

@andrei-m-code

Features, not syntax.

[svick]

@andrei-m-code

But even the case with Action is a bad practice - don't leave unreachable code!

The issue does not depend on unreachable code:

M(() => {
    if (condition)
    return
    f()
    throw new Exception()
});

Method overloads with generics, extension methods and implicit type casting is a pretty big mess, so I'd say we have some gotchas in the syntax already.

I think that's an argument against adding new gotchas, not for adding them.

Do you think where Linq came from or ?. or extension methods or async/await.

None of those features affect the basic syntax of C#, they just add some new constructs to it.

And at least in the case of LINQ and async-await, the features were strongly inspired by other languages (SQL and functional languages; F#), but the syntax was not directly taken from those other languages. Instead, a syntax that works well with the rest of the language and is backwards-compatible was chosen.

Kotlin has optional semicolons that work well? Cool. Can C# directly take Kotlin's design? I don't think so:

In Kotlin, semicolons are optional, and therefore line breaks are significant. The language design assumes Java-style braces, and you may encounter surprising behavior if you try to use a different formatting style.

I think this means that Kotlin's design wouldn't work in C#, because most C# code uses Allman-style braces.

Is there some way to create a similar feature that would work well in C# and was backwards-compatible? I doubt it.

[jnm2]

IIRC, async/await was pioneered in C# and now other languages such as JavaScript have copied it.

[andrei-m-code]

I mean, it's possible and Kotlin, Swift and Go have proven that it works and can be done right. And damn, even if formatting would matter - who cares, if someone doesn't know how to properly format code, his PR is declined until it's fixed, at least in my company. I see why C# creators wouldn't want to do this - because

1. It has too much conservative resistance in community. I wonder what would people say if it's announced by Scott Gu/Hu/Ha. I'm sure the reaction would be different.
2. Compatibility concerns - C# +1 though doesn't have to be compatible with C#. Hell why? However older versions would have ";" so it's would work just fine.
3. Too hard to implement in general, they had enough with dirty async/await hack already.

And let me make sure, everybody knows that it's an end of statement ;

[TomasHubelbauer]

It's a big stretch to go from "semicolons should be optional" (which I disagree with but could see myself maybe switching gears on if it was implemented and really worked without any gotchas seen in other languages) to "whitespace should be significant" (which I disagree with and don't see ever agreeing to and I have a suspicion I am far from alone on this).

And I general, even today, there are C# users who don't even use source control, much less a review process. You may think it's okay to throw these people under the bus, but the fact that C# was so good to current users for so long with backwards compatibility was a huge boon to its success.

[HaloFour]

@andrei-m-code

if someone doesn't know how to properly format code, his PR is declined until it's fixed,

And why should someone's opinion regarding "proper formatting" be codified into the language? What if the format adopted was not the one espoused by your company or yourself? Why should all of your code suddenly be invalid?

I really like the fact that C# doesn't force a style. They can pry K&R from my cold dead hands.

[svick]

@jnm2 F# had it first, though with very different syntax.

F# added computation expressions, which are used for asynchronous workflows, in F# 2.0 in 2010. C# then added async-await in C# 5.0 in 2012.

[iam3yal]

@andrei-m-code

It has too much conservative resistance in community. I wonder what would people say if it's announced by Scott Gu/Hu/Ha. I'm sure the reaction would be different.

It's not about resistance, it's about facts and reasons and it doesn't matter who is the guy proposing it.

Seriously.

Compatibility concerns - C# +1 though doesn't have to be compatible with C#. Hell why? However older versions would have ";" so it's would work just fine.

It will probably work fine but why investing in something that while have some value requires a lot of efforts for extremely small benefit?

Too hard to implement in general, they had enough with dirty async/await hack already I'm sure.

This sentence doesn't make sense.

[theunrepentantgeek]

Too hard to implement in general, they had enough with dirty async/await hack already I'm sure.

You should go look at the implementation of async/await in the Rosyln compiler before you start dismissing it as a dirty hack.

[yaakov-h]

However older versions would have ";" so it's would work just fine.

Can you guarantee though that C# 9 will be backwards compatible with C# 8 if 8 removes the need for semicolons? How about C# 10? 11?

[jnm2]

@svick

@jnm2 F# had it first, though with very different syntax.

F# added computation expressions, which are used for asynchronous workflows, in F# 2.0 in 2010. C# then added async-await in C# 5.0 in 2012.

Cool. Did F#'s async work on the basis of coroutines so that there would be no threadpool thread being blocked while awaiting I/O?

[bondsbw]

The only two proposals for getting rid of semicolons that I can stomach are:

1. Optional semicolon for final statement in a block

   public void Guard(bool b)
   {
   if (b)
   {
       Console.WriteLine("Guard passed.");
       return
   }
   Console.WriteLine("Throwing exception...");
   throw GuardException()
   }

2. Part of a "light" syntax mode that makes the language more whitespace sensitive

   
   #light

...

public void Guard(bool b) if (b) Console.WriteLine("Guard passed.") return Console.WriteLine("Throwing exception...") throw GuardException()

Light mode effectively means maintaining two languages, so I don't see that being much of a priority unless Microsoft can be convinced to throw a lot more money at designing a language that it considers to be very stable.

[ufcpp]

https://github.com/dotnet/roslyn/issues/13731 D#

[gafter]

who needs punctuation punctuation is so redundant our languages already have so much redundancy why should we add more English is bad enough why should C# have punctuation too imagine being able to repurpose all those keys think how much longer our disks would last without being filled up with useless punctuation in conclusion yes please go ahead and remove semocolons

Seriously... this is a category of change we'd not consider.

[HaloFour]

@gafter, the next Timothy Dexter. You can use the empty statement for your second edition.

[AustinBryan]

Great because nothing better than living in the world where this

if (x)
{
    print ("Swag")
   print ("Dope")
}

Won't compile. If you think semicolon errors are bad, about indentation errors? I wasted so much time at college trying to find out where the error was because sometimes it looked like it was aligned, but in reality it wasn't because the tabs and spaces were mixed.

I know in this example you can tell it's not indented correctly, but there's been times when it did.

Also, you'd be breaking so much preexisting code, all, for what? There's literally zero gain from making ; optional. C# does not care about whitespace and you'd be making it do so, but for almost two decades now people haven't cared too much about their whitespace either.

[LeonG-ZA]

I hate ASI in JavaScript because it forces you to put brackets on the same line as the statements otherwise the meaning of the statement is misunderstood. I like my whitespace freedom, thanks. Imagine all the old code examples + tutorials not working correctly anymore...

It's too difficult too implement correctly and not even Kotlin gets semicolon insertion right: https://android.jlelse.eu/why-i-missed-semi-colons-today-e2fb136f58e5

[JohnnyXP64]

another reason why vb.net is so much better and faster in syntax! 💃 and if vb.net has that for decades then c# could have it to!

[jnm2]

https://vimeo.com/111122950#t=12m19s 😃

[HaloFour]

@JohnnyXP64

I know you meant that as a joke but VB.NET is a fantastic example as to what happens when you try to take necessary syntax and make it optional. In VB.NET a newline is a statement terminator. If you want to have two statements on one line you need :. If you want a single statement to span multiple lines you need _ at the end of each line. At least you did until VB2010 when they decided to try to make _ optional. They iterated on this several times since, but it's proven impossible to eliminate the need for _ entirely, and now the result is that sometimes you need it and sometimes you don't. Sometimes the IDE can automatically put one there when the result would be a syntax error. But if it's not, neither the IDE nor the compiler can correctly interpret what you had intended.

Punctuation is important. It's what allows us to determine whether or not the panda is a gangster or an herbivore.

[JohnnyXP64]

@HaloFour i was not Joking! i love VB.net and its syntax in vs2017 is by FAR suppierior to all c# nonsense that inherit from the annoying c++ with {} and ;;;; jsut so that microsoft can attract the c++ and the java and the pascal developers to .NET.

new lines can be detected as you said now with a simple enter nomore need for _ even verbally is so much more advanced. AND not && OR not || and other annoying symbols, but i dont want to turn this into a vb.net vs c# .... i just want the annoying ;;;;;;;;; in c# to die.

plus oot if vb.net was named B# (beSharp) would be cooler

[helsirsy]

@HaloFour i was not Joking! i love VB.net and its syntax in vs2017 is by FAR suppierior to all c# nonsense that inherit from the annoying c++ with {} and ;;;; jsut so that microsoft can attract the c++ and the java and the pascal developers to .NET.

new lines can be detected as you said now with a simple enter nomore need for _ even verbally is so much more advanced. AND not && OR not || and other annoying symbols, but i dont want to turn this into a vb.net vs c# .... i just want the annoying ;;;;;;;;; in c# to die.

plus oot if vb.net was named B# (beSharp) would be cooler I totally agree with you Johnny, and me to love vb.net and its ease of use logical understanding. On the other hand unfortunately people run behind every new, so I think B# will be coll, although I like vb.net as it.

[LifeIsStrange]

Just to say that the fastest growing programming language (python) doesn't have semicolons. And that one of the most used javascript/typescript style guide say no to semicolons. https://standardjs.com

The rationale is not only that this would prevent annoying missing semicolons errors, but that human brains can't totally ignore semicolons and that they are a background mental load/complexity that should be avoided. If Microsoft really care about developper experience (and I know they do) they should go beyond the programming myths and do some science. I propose to Microsoft to make a scientific study that capture on a sample of programming exercices how disabling or enabling semicolons affect programmers efficiency/bugs/etc. Other metrics could be how semicolons affect memory retention and attention about the lines of codes. In addition, it would be interesting to get big data analytics of productivity/bug counts of e.g javascript open source projects that enforce or disallow semi colons.

More generally, the future best programming language will be the one that do scientific inquiries about language design choices.

[HaloFour]

@LifeIsStrange

The rationale is not only that this would prevent annoying missing semicolons errors,

TL;DR: No

I'll take missing semicolons errors anyday of the week over ambiguous and silent logic errors caused by the lack of them.

Python was designed from the get-go to be whitespace sensitive. Trying to backport Python to be whitespace insensitive would be just as fraught with problems (and just as well received).

JavaScript is a horrid mess and should never be held up as an example of how to design the grammar of a language. Any style guide that suggests omitting semicolons needs to also very strongly suggest following other very specific formatting rules otherwise you're guaranteed to run into a situation where semicolon insertion will silently change (and break) the meaning of your code.

Trying to remove semicolons from C# would be a massive waste of time. It could never be managed 100% due to the reliance on statement terminators to eliminate ambiguities. And it would result in negative productivity where some devs would feel the need to go and remove semicolons from code that works perfectly fine.

[theunrepentantgeek]

The science of semicolons is very simple: The syntax of C# is such that semi-colons are necessary to avoid ambiguity.

Python had the luxury of designing syntax to avoid explicit statement terminators from the very start - and they chose to use semantic whitespace instead.

JavaScript made them optional ... and created headaches for every implementation since then.

More generally, the future best programming language will be the one that do scientific inquiries about language design choices.

Arguably, whether or not a programming language is "the best" has very little to do with popularity. JavaScript and PHP are wildly successful - and yet many would argue that they are intrinsically flawed.

[kumarc-ps]

C# has been the language of a few major developers' choice. The choice meaning that the language design/development community is very limited and is based on several personal opinions of very few people. That is if a person agrees/disagrees to a proposal, whether it's right or wrong is entirely dependent on that person's opinion. This is making the developers to write boilerplate code till today.

Examples

1. Semicolons - Completely useless IMO, except a great/impressive or whatever programmer chooses to write two statements in one line.
2. Enumerations - We still need to write enum's name with case every time we access. In Swift it's just starting with a .(dot).
3. To make an enum have a method (e.g description), we need to write extension methods. Again, please learn/steal/borrow the ideas from modern languages like Swift.
4. Class extensions are still following the old convention. It could've been improved or least a few inputs could've been taken fro Swift's class extensions.
5. There are read only structs but not classes. Now there's a proposal to make read only classes which are almost similar to record types. What is the point of making record types? Is record type can be improved A lot of opinionated features are being stuffed into the language. Now we have 3 ways of structuring a model each with very thin abstraction.
6. In Swift an enum can be of any type. We still follow the legacy model of only integer types.

To list there are a lot of things. Being unique doesn't mean being old or worse.

[HaloFour]

Brian Goetz on the value of removing semicolons: https://youtu.be/BL6ba2dtprw?t=3207

It's one thing when a language is being initially designed and statement terminators are being considered. It's another thing entirely to try to retrofit them out of a 20 year old language.

[andrei-m-code]

@HaloFour

1. Brian Goetz - don't know who this guy is but it doesn't matter. His arguments make no sense. "Negative value blah blah?" it's very questionable. I can't recall how many times my code compiling failed because I forgot to put this useless ";" at the end of the line. Companies really don't have to focus on removing semicolons from "perfectly working code" unless their developers have nothing better to do. So NO, I don't buy it.

2. I understand that it's a bit complicated to make semicolons optional. Still - it is doable, I'd be fine if it's an experimental feature for starters e.g.:

   <PropertyGroup>
   <TargetFramework>net5.0</TargetFramework>
   <OptionalSemicolons>true</OptionalSemicolons>
   </PropertyGroup>

   It would work great for any new project.

3. "retrofit them out of a 20 year old language"? It doesn't mean that semicolons would be completely removed, instead they can just be optional - it shouldn't break existing code. Javascript made it optional and I never ever had any issues with it. It's a normal language evolution. If you like your 20yo stuff, keep on for looping instead of using LINQ and don't you dare using default method parameters.

4. Semicolon lovers may say it's just a ";" - not a big deal. Now, here I am opening one of my 3 year old project and finding the number of semicolons in it. 70 000+!!! Talking about efficiency here. Try to press a single button 70 000 times and see how long it will take you to get to this number. Guys please go ahead and open your projects and see how many you got there. Who's the winner?

Bottomline: it is absolutely useless, non-efficient, even ugly. This is one of the reasons why I use F# for some of my pet projects. We should be making it optional at least for new projects. Semicolon cancer - gotta be removed. Forgive me my pun.

[HaloFour]

@andrei-m-code

Brian Goetz - don't know who this guy is but it doesn't matter.

Java Language Architect

I understand that it's a bit complicated to make semicolons optional

No, not a bit complicated. Enormously complicated. The language was designed around their existence as a means of unambiguously parsing code. There will be many circumstances where their removal will lead to ambiguities that can only be resolved by requiring they remain. So instead of the burden of requiring semicolons everywhere, now you have the burden of trying to remember all of the places where semicolons are still required.

And, at the end of the day, that enormous amount of effort to remove semicolons from the language creates ZERO benefit. It doesn't enable a single developer to solve any new problems. It doesn't appreciably change anything about the code. All it does is placate the stylistic preferences of those developers who'd rather be using a different language. And I doubt those complaints will stop at semicolons.

[HaloFour]

@andrei-m-code

Now, here I am opening one of my 3 year old project and finding the number of semicolons in it. 70 000+!!! Talking about efficiency here. Try to press a single button 70 000 times and see how long it will take you to get to this number. Guys please go ahead and open your projects and see how many you got there. Who's the winner?

The number of keystrokes you have to type isn't relevant. Code is read orders of magnitude more often than written, and the grammar should be optimized for that case.

You should check out some of the languages of the 70s and early 80s where the designers thought it would be a good idea to allow any keyword to be abbreviated as long as it was unambiguous. Fewer keystrokes leading to nearly incomprehensible code:

M()
       N S,N,T,I,K,Q S I="K",S="11",K="l1",Q="R",T="K"
       I I=T D T
       Q:$Q Q Q
T  I I,S&K S S=S+K Q

[bernd5]

For me a semicolon improves very much the readability of code!

But if you came for example from a python background you may think different to it (there semicolons are optional).

And I think it would be quite easy to change the roslyn compiler to make semicolons optional. Roslyn currently emits MissingToken(SyntaxKind.SemicolonToken) where a semicolon is missing in an ExpressionStatementSyntax. In addition it does not really separate statements - we have a lot of statement-types without semicolons like if, while or block.

But I'm still not sure if it would improve code!

@kumarc-ps: if you see some nice features in other languages you wish would exist in CSharp - please start a discussion for those features (like the deduced enum type in assginment or switch expressions from swift).

[andrei-m-code]

@bernd5 @HaloFour

You guys a way too conservative with it. Look into your code and ask yourself: what would change with readability (and "reliability") if semicolons are gone? - Hey, NO! Don't just read it and move on. Open your IDE and actually look at your code. Do you really think it's necessary?

JS did it and it reads (and writes) a lot better now.

I didn't come to C# from a different eco-system, C# was always my primary language. But I'm willing to lift my eyes from the keyboard and actually look around and see what's new and cool happening with other languages like Kotlin, Swift, JS/TS, Python, Go etc. C# must innovate fast - and they do, don't get me wrong. But they keep losing developers to languages that are more advanced and clean. I want C# to be successful. Innovation is painful sometimes but no pain - no gain.

I don't find it's opinionated, I think it's very principal. Either you want to innovate, or you want to stay in your comfort zone.

[LeonG-ZA]

@HaloFour

1. Brian Goetz - don't know who this guy is but it doesn't matter. His arguments make no sense. "Negative value blah blah?" it's very questionable. I can't recall how many times my code compiling failed because I forgot to put this useless ";" at the end of the line. Companies really don't have to focus on removing semicolons from "perfectly working code" unless their developers have nothing better to do. So NO, I don't buy it.

I've been doing C# for more than 10 years now and I can't even remember when the last time was when forgot a semicolon. I think maybe 2 times in the first few days while learning C#. Even if you forgot a semicolon and it doesn't build, how many seconds does it really take up to put one in? I do however remember many times ASI kicked me in the butt with JavaScript. Personally I don't want to encounter those nightmares ever again.

[HaloFour]

@andrei-m-code

You guys a way too conservative with it.

Language design is intentionally conservative, especially for a 20 year old language. When trillions of lines of existing code lie in the balance every possible change needs to be weighed extremely carefully.

Look into your code and ask yourself: what would change with readability (and "reliability") if semicolons are gone?

More importantly, does it decrease readability (or "reliability") if those semicolons are there? Nope, not even a little.

JS did it and it reads (and writes) a lot better now.

Automatic semicolon insertion made it into the "Awful Parts" appendix of the relatively short "Javascript: The Good Parts" book for a reason. It creates ambiguities in the parsing of the code which introduces bugs that manifest at runtime. Javascript reads objectively worse for lack of semicolons as you now have to be very aware of how the code is interpreted without them. And what's worse is that these ambiguities (and resulting runtime bugs) manifest even if you are using semicolons. Javascript's attempt to make semicolons optional is an exceptional example of why it is a bad idea.

C# must innovate fast - and they do, don't get me wrong. But they keep losing developers to languages that are more advanced and clean.

4 of the top 5 languages of the TiOBE index require semicolons. The popularity or adoption of a language is not correlated to whether or not it has semicolons.

Either you want to innovate, or you want to stay in your comfort zone.

This has nothing to do with comfort. I use many different languages which are parsed differently. Many don't have statement terminators. I don't find it less comfortable to use them at all. But those languages were designed to be parsed in that manner and it affects the evolution of their grammar a great deal. Languages that try to paradigmatically change that design after the fact are the ones which are the least comfortable because they invariably retain the "warts" of those earlier design choices and the onus is on the developer to know when and how they have to revert to the older styles.

Removing semicolons isn't innovative. It's a giant waste of time and effort better spent on actually bringing useful features to the language.