[Proposal] [Syntax Sugar] Accessibility blocks for class members

[GuiAmPm]

I can't find another issue on the subject, sorry if this is duplicate.

Proposal:
I'd like to propose something like we have in C++ when declaring a bunch of type members to group them by the accessibility level.

In C++:

class A {
   private:
      string a;
   public:
       int b;
       char c;
}

The idea is not turn C# into C++, but to reduce boilerplate code and help organize members better inside the type, so I guess the way C++ declare these blocks wouldn't work in C#, as members in the
later are supposed to be organized in another order as the guidelines go.

So maybe blocks with beginning and end would be more interesting as they can be mixed with the common way of declaring members, something like:

class A 
{
   private string B { get; set; }

   public 
   {
       int C { get; set; }
       char D { get; private set; }
   }

   protected string E { get; set; }

   private A() { /* constructor */ }

   public 
   {
      A(string) { /* constructor */ }

      string InstanceMethod() {/* ... */}

      string static StaticMethod() {/* ... */}
   }
}

Motivation:
Classes with a large number of members have a lot of information that doesn't add reading value to the code ( blocks with lots of public/private/protected members, one after the other or classes enterely made of public members)

Impact:
As this is only syntax sugar, I believe the impact would be only superficial. When compiled, the code would behave like it was declared normaly with the accessibility keyword.

Taking it beyond
Maybe grouping other keywords as well. But maybe it will get a bit convoluted:

class A 
{
   public static 
   {
      int StaticMethodA();
      string StaticMethodB();
   }

   public int
   {
      PropA { get; set; }
      PropB { get; set;}
   
      CalculateA();
      CalculateB();
   }
}

Acknowledged issues with my proposal:
The only problem with using brackets is that it seems like we are isolating those members, not classifying them, turning the code convoluted. Maybe another way to limit those blocks would look better.

[iam3yal]

@GuiAmPm

Classes with a large number of members have a lot of information that doesn't add reading value to the code ( blocks with lots of public/private/protected members, one after the other or classes enterely made of public members)

Wouldn't it make sense to break it up to multiple classes then? than having them all in a single class? how about using regions?

[GuiAmPm]

@eyalsk You will still have to write accessibility and keywords for each member, plus for the new class(es) so you will end up with more boilerplate code. The focus of the proposal is to reduce boilerplate code, not reducing the class' density or hiding members.

[iam3yal]

@GuiAmPm Fair enough even though I think that the "boilerplate" provides clarity so you reduce the amount of code you write but at the same time you reduce its readability, now, this is clearly an opinion and not a fact but this is how I feel about it. :)

I'm one of these who dislike regions and partial classes, especially when people abuse the latter to break a large class into multiple files where it should have been multiple classes.

[GuiAmPm]

@eyalsk Yeah, I wouldn't like to sacrifice readability nor the C#'s "personality" on this aspect (I prefer the way C#'s member order over C++'s). But take a larger class in one of your projects and collapse it and you will notice how many times "public, public, public" or "private, private, private" members stick together or how every member of a transport class (for example) is public and yet you had to write it for each one of them.

I'm trying to find a middle ground between "Write Less, Do More" and Readability. That and I'm a bit lazy. :D

[jnm2]

Very similar to #818.

[SlimeNull]

I think this is very useful, hope MS can see this and do something (?

Maybe you can create issue for this discussion

[333fred]

Issues are only created for things the LDM would like to champion. No one from the LDM has expressed interest in championing this. For myself, I quite dislike this feature of C++ and don't think we need another, different way of declaring members.