Shorthand syntax for closing braces

[lazyloader]

Why not instead of doing

namespace N
    {
    class C
        {
        public void Foo()
            { 
                if (someCondition)
                    {
                    }
               else
                  {
                  }
               }
            }
        }
    }//lots of lines that are just braces

we could just simply do something like

namespace N
    {
    class C
        {
        public void Foo()
            { 
                if (someCondition)
                    {
                    }
               else
                  {
   }.. //will automatically add all the braces

other ideas could be }..., } all, end, braces, etc.

The result is it is much more readible and easier to understand without having to waste so many lines of code of just tabs, on complete code-bloat.

[HaloFour]

The result is it is much more readible and easier to understand without having to waste so many lines of code of just tabs, on complete code-bloat.

No, it's not. It's a hideous mess.

[jnm2]

Can't imagine this would have a different reception than #1441.

[lazyloader]

That was poorly recieved because the ! operator is ambigious, was using a poor coding practice, and the problem could be solved using pipe operators. My purposal has none of those issues.

[jnm2]

@lazyloader This proposal is probably going to be poorly received because of the distracting brace indentation style (don't take this the wrong way, but both examples were hard for me to read), and after that, because of your assertion that the lines of closing braces we write today are "complete code bloat."

[theunrepentantgeek]

I rather think #1441 received a poor reception because skipping closing delimiters is a really bad idea. They're no more code bloat than good spelling or correct grammar in English.

Shorter code isn't automatically better.

[scalablecory]

You should not endeavour to create scope mountains. Reorganize your code instead of looking for workarounds.

C# is not a language of significant whitespace, so this is not very idiomatic.

[HaloFour]

Think about it. There's only one possible place where such a syntax is even remotely applicable, and that is at the last part of the last method of the last type declared within a file, and only if the very last statement itself happens to be nested multiple levels deep. It's useless anywhere else as it would close the definition of the method, type and namespace where it would be used, preventing you from declaring anything afterwards without even more boilerplate than would've otherwise been necessary.

[Unknown6656]

@lazyloader
Just an honest question out of pure curiosity:

Why are you proposing such language changes?
#1659
#1651
#1619
... and this one

It seems to me that you are rather unhappy with the C# syntax in its current form -- and that's OK.
The problem is, that C# is originally a C-style language (with minor functional additions), but it goes a bit against the language when such drastic syntax changes would be implemented.

I would therefore like to ask you: Why aren't you using an other language?
You could switch to F#, which would kind of have one-liner classes and then after if. You would not even have to use closing }s.

[lazyloader]

@Unknown6656 It's not my call. Unity was mostly designed for C# (and other langauges but mostly everyone uses C#) and that's what the rest of the team is using so it would be weird to try and use some hacked F# when only one of us would be using it.

Thing is though I do love C#. I mean, how many other mainstream languages can use expression bodied methods, have properties, or do stuff like turn this

public MyClass(Arg1 arg1, Arg2, arg2, Arg3 arg3)
    {
    Arg1 = arg1;
    Arg2 = arg2;
    Arg3 = arg3;
    }

into this

public MyClass(Arg1 arg1, Arg2, arg2, Arg3 arg3) => (Arg1, Arg2, Arg3) = (arg1, arg2, arg3);

And from my understanding, records will be making that even easier?

It's cool working in such an active language that's constantly improving and adding new features. I'm exicited for the future of C# and where it's going and it would be cool to request a feature that makes it in.

C# has had a lot of features that tried moving fluff from the code (some of my favorite features) which is why I purpose those, to try and shorten the code (or improve readability).

[Unknown6656]

@lazyloader : I completely understand your position concerning the "pressure" of your dev team to work with C# instead of a functional language to keep internal consistency.
I am, however, glad that you love C# even as a "private person" (not only as a company's employee).

---

I can completely understand your thirst to suggest a feature that will make it into the actual release of a C#-version, however I have the feeling that you are going in a kind of a wrong direction.
I hope that I can elaborate my thoughts:

It is important to suggest features, that are not only existent to "be a part of the C# LDT", e.g.:
When I first stumbled upon the roslyn-repo, I was eager to propose a new operator - partly because I thought it could really help me; and partly because I felt, that I would be "a part of" C# if it would pass the release-stage.
Of course, it was a "niche" operator and was therefore rejected without deeper discussions.

I quickly learned, that one must broaden their minds and also think about "missing features" as follows:
Instead of asking: "Could you put X into the next iteration of C#, please?"
We must ask ourselves: "Why would we need it (now)?"
Very often, a "missing feature" is a hint for unclean code and/or bad coding practise.

Furthermore, it is important to develop features which serve a wide number of C# devs and are not the future source of bad coding practises themselves.

Example

I will take your proposal #1651 as example:
Questions we could ask ourselves before proposing such a new feature could be:

• Why would we need implicitly typed comments?
• Wouldn't this resort in syntax ambiguity?
• Why do we need this in the first place?
• Do we write to much comments?
• Why do we do this?
• Is our documentation bad?
• Is our code unreadable?
• Is it spaghetti-code?
• ...

Just simply asking these questions before submitting a proposal can help take an objective view of the proposal's usage cases and need.

---

Now, I am not thinking or saying, that you didn't think about your proposals before submitting them here - What I am simply saying is, that it is important to take a broader and more critical view on the entire matter.

TL;DR

Follow the 'checklist' before proposing a new feature:

• Do we need this feature?
• Is it a sign of bad coding practise`
• Better writability (aka "shorter code") =/= Better readability !!
• How many people will use it?
• Must it be a compiler-feature or could a code analyzer resolve this?
• Optimally, propose a syntax definition or -- even better -- a prototype for your feature.

---

Indecently, do please forgive my ignorance, but I thought that Unity could be used with F# - can't it?

---

... Aaaaand here comes a very important final note:

I know that we (the LDT and the majority of the community) may seem like utter assholes for "downvoting" or "rejecting" some of your ideas - but the following is important:

1. We do not mean it personally
2. The task of the LDT is to "control" the flow of proposals from community in order to make sure that C# will still be a awesome language in the future.

[sharwell]

@lazyloader There are a number of issues with the proposal, but the main problem I see with this proposal is it only works at the end of the file. It turns out this is also the one place in a source file where a long sequence of curly braces is easily ignorable (because it already had no code following it). A few other alternatives are available as well, such as switching to the use of One True Brace instead of the Allman style more commonly seen in C# code.

💭 What if instead of this proposal, the IDE had a command to close any remaining braces? At worst that would be fairly easy to implement in an extension (if it doesn't already exist).

[jnm2]

@sharwell That's a great idea. I could see myself using that to insert closing parens, too.

[DavidArno]

Since the OP is using the Whitesmiths style of braces, which every C# developer on the planet save for @lazyloader finds unreadable, the solution to this seems obvious to me:

namespace N
    {
    class C
        {
        public void Foo()
            { 
            if (someCondition)
                {
                }
            else
                {
                }}}}}

It's still completely unreadable, but is no worse than before. And it now avoids "lots of lines that are just braces" as @lazyloader wanted. Problem solved.