Not require round brackets for if statements

[PlayCreatively]

I'm mostly wondering why this hasn't been implemented yet. What does it break?

The incentive being to reduce bracket soup. A light example would be if (IsTrue()) { } would be if IsTrue() { }. It's more readable and in the cases where you have many round brackets it helps to have the overall amount reduced.

single line if statements that ditch the curly brackets would however still require round brackets but that also isn't bad as it's more readable that way.

I'm semi dyslexic and often have a hard time reading code with multiple brackets competing for my attention; so places where we can reduce bracket clutter is a plus for readability.

[CyrusNajmabadi]

I'm mostly wondering why this hasn't been implemented yet

Because no one on hte LDM believes enough that this is a step the language should take to push for it to happen.

I was a supporter of allowing one to write if !(foo()) instead of if (!(foo()). But htat would still require one set of parens. We discussed this in the LDM and decided to not go with this.

It's more readable

This is debatable. There's research i've read that talks about how having more htan one way to do something can hinder readability. So we have to feel the value this brings outweighs these (and other) sorts of costs.

I'm semi dyslexic and often have a hard time reading code with multiple brackets competing for my attention; so places where we can reduce bracket clutter is a plus for readability.

I'm sympathetic to that. However, while this might be a benefit for some, that has to be weighed against it being a negative for other.

What does it break?

It makes many things ambiguous. For example:

if GetSomeDelegate()
   (DoSomething() + SomethingElse()).Whatever();

What does that mean? is hte condition of the if GetSomeDelegate() ? Or is it GetSomeDelegate()(DoSomething() + SomethingElse()).Whatever() ?

[CyrusNajmabadi]

Well like I said. In those instances you would not be permitted to remove the round brackets

Ah, you did say that. here's another example though:

if new Foo() { ... }

Is this:

if (new Foo())
{
}

or is it:

if (new Foo() { ... })

(note that this is legal in C# as 'Foo' may be implicitly convertible to a boolean, or may have an operator true/false :) Fun times.

Really appreciate the detailed answer, thank you.

Absolutely. And this is definitely a great venue to ask questions so feel free to keep them coming. Of course, you're also welcome to come visit gitter.im/dotnet/csharplang and discord.gg/csharp to talk live with the community and team members directly :)

[theunrepentantgeek]

In those instances you would not be permitted to remove the round brackets.

As I understand it, at the point in the Roslyn C# compiler where it's parsing the text, it has no knowledge of the types of things.

It doesn't know whether GetSomeDelegate() returns a bool or a Func<T> or something else - and it thus doesn't have any information from which to decide whether the brackets should be optional or not.

By contrast, the Go language was able to do without brackets because the { braces } are mandatory; there's no such thing as a single line if.

There are a bunch of places in C# like this - places where things could have been done differently, where they likely would have been done differently had the language designers known what we know now, but where making changes after 20 years and billions of lines of code is somewhere between extremely impractical and completely impossible.

[angryLittleHamster]

When you have simple one statement actions, I would really like to see a feature for the if statement that will allow me to write the following:

if (!outputFile.Directory.Exists)
{
    outputFile.Directory.Create();
}

as follows:

!outputFile.Directory.Exists => outputFile.Directory.Create();

[HaloFour]

You can already write it like this:

if (!outputFile.Directory.Exists) outputFile.Directory.Create();

[PlayCreatively]

@HaloFour I get what he's saying. In his example he's able to get rid of both the if and the parentheses for a more clean visual

    condition => statement

However, @angryLittleHamster, for the little I know, I'm pretty sure it would create difficulty for the compiler to differentiate between this and lambdas.