Feature Request: Inferred static keyword for members in static classes.

[Spaier]

Since everything in static classes is static as well it would be nice not to write static keyword in every method, property, etc.
Before:

static class Extensions
{
    public static int StaticProperty { get; set; }
    public static void StaticMethod() { }
}

After:

static class Extensions
{
    public int StaticProperty { get; set; }
    public static int ExplicitStaticProperty { get; set; }
    public void StaticMethod() { }
    public static void ExplicitStaticMethod() { }
}

[jnm2]

I'm not really happy that every member would become an instance member during a refactoring; for example, making the class instantiable or moving members to a different class.

[Joe4evr]

What @jnm2 said: Today, a static class is always safe to refactor into a non-static class in a later release without breaking any compatibility. This proposal would make such a refactoring a very large breaking change for no reason.

[AustinBryan]

Having explicitly static members just makes it even more confusing, it would make me forget I'm working in a static class. Also, public int already means something, it means a public instance integer. This would be basically changing that meaning which would be confusing and cause refactoring issues.

[DavidArno]

I am with @Spaier in thinking that the static prefix to members of a static class are superfluous. Also, I find the "but I might want to refactor it" a very weak one. But that's because I use static classes as a way of defining a module of free functions. Taking that module and turning it into an instantiable class is not refactoring; it's fundamentally changing the purpose of the code. As such I dislike the fact that fundamental change can be achieved by just dropping the static with no affect upon the rest of the code. I want the results of changing a class from static to instantiable to be catastrophic to the compilation.
But this discussion has been had before and I sit with the minority with this view and the team appear to side with the majority here. Further, the example code in the OP shows a real problem with the idea:

static class Extensions
{
    public int StaticProperty { get; set; }
    public static int ExplicitStaticProperty { get; set; }
    public void StaticMethod() { }
    public static void ExplicitStaticMethod() { }
}

That mixture of members, some static and some not would have to be legal syntax with this proposal, to avoid breaking existing code. But it’s confusing. I reread the OP a couple of times trying to work out the significance of some being marked static. But there is none. To my mind, this is the worst of both worlds.
I feel that the solution to this that would satisfy everyone is to allow the creation of module of free functions, using a module keyword, rather than overloading the static class notation:

module Extentions
{
    public int Foo() => ...
}

Here, the static keyword would not be allowed, avoiding the confusion of mixing them as per the OP's example. And the module keyword makes clear that this isn't a class, and that turning it into a class would fundamentally change the semantics, such as those free functions suddenly becoming instance members.

[AustinBryan]

@DavidArno You definitely nailed the "getting best of both worlds." I didn't like either that adding static in the new static classes didn't change anything, and I felt it would only steepen the learning curve for little gain, while I did think that having to write static each time was kind over the the top.

Just out of curiosity, if something is a module, would we still have do using static Extensions; to access the methods without the type name, or could we just do using Extensions; It would be nice if the later, because right now, if we use a class without the using statement, we can do ctrl + . and add the proper using statement, but that feature has yet been added for methods and static classes. Also, that would feel very close to having namespace level functions, as requested here #1180

[wizofaus]

That mixture of members, some static and some not would have to be legal syntax with this proposal, to avoid breaking existing code. But it’s confusing. I reread the OP a couple of times trying to work out the significance of some being marked static. But there is none. To my mind, this is the worst of both worlds.

It might need to be legal syntactically, but it needn't be legal code. It could simply be a rule that either you specify static for all members, or you don't specify for any. And certainly I'd like to UI to strongly encourage removing all 'statics' by a simple click.

But in the scope of things it's a minor annoyance, and I agree if there's not enough in favour of the change it's not worth the effort of getting changed.

[theunrepentantgeek]

C# has preferred, to this point at least, being quite explicit about many things. Methods and properties aren't virtual by default, you have to opt-in to allowing them to be overridden. You also can't override a method in a descendant class just by redeclaring it - you have to explicitly state override if you want that behavior.

Perhaps the biggest reason why I think it's a good that static methods are always explicitly marked as static is that some codebases contain very large classes. (I'm not going to touch on whether that's good or not - but it is definitely true.)

Consider this declaration:

public string Description() => "Transmogrify the rotation frequency of the shields";

I suggest it would be quite confusing if this method was sometimes static, and sometimes not; just as it would be quite confusing if this method was sometimes virtual, and sometimes not.

[wizofaus]

I suggest it would be quite confusing if this method was sometimes static, and sometimes not; just as it would be quite confusing if this method was sometimes virtual, and sometimes not.

Assuming the difference matters, sure. But if it doesn't - i.e. whether or not you declare a member on a static class as "static" actually makes no difference to the behavior, then it's no more confusing than the fact that you can write either public static or static public, or CallThisFunction(value) vs this.CallThisFunction(argName: value).

[CyrusNajmabadi]

But if it doesn't - i.e. whether or not you declare a member on a static class as "static" actually makes no difference to the behavior, then it's no more confusing than the fact that you can write either public static or static public

It's definitely more confusing. With public static or static public i can see at the declaration site what is going on. If we allowed static to be left off of a member, it would become much harder to tell "is this member static?"

[CyrusNajmabadi]

Assuming the difference matters, sure. But if it doesn't

The difference definitely matters to me. When i see a method, knowing whether it is static or not is absolutely a core part of what i want to know about it and how i will think about it. So eliding that information would not be desirable for me at all, and it would actively make things like code review and maintenance harder.

[wizofaus]

Assuming the difference matters, sure. But if it doesn't

The difference definitely matters to me. When i see a method, knowing whether it is static or not is absolutely a core part of what i want to know about it and how i will think about it.

Well I can't say I understand that in this case, but obviously others feel the same way, so I'll save my energy for changes that would truly enhance the power of C# (like non-nullable references, or discriminated unions/sum types)!

(PS. how is 'static' being optional any different to 'private' being optional? You can declare a class with a mixture of members some of which are declared 'private' and others not, and developers as a rule don't seem to get thrown by it).

[DavidArno]

@theunrepentantgeek,

C# has preferred, to this point at least, being quite explicit about many things...

This is both a good and a bad thing. For example, it's good that eg methods aren't virtual by default and that they must be explicitly marked as such. The problem arises though when development methods change and the default becomes "wrong". For example, fields are not read-only by default; I have to explicitly mark them as such. And for folk who use a more functionally orientated approach to things, the fact that methods aren't static and pure by default and classes aren't sealed by default becomes a nuisance as nearly everything has to be explicitly marked that way.

But there's no easy, tidy solution to this:

1. Leave things as they are. Annoying in that the defaults are often now the wrong way around,
2. Make changes like this proposal of removing the need to mark members of a static class as static themselves. This can lead to confusion as you describe though and some worry about the impact on changing a class from static to not (though I've never accepted that line of reasoning, personally).
3. Invent new syntax, eg introduce the concept of a module as I describe above that replaces static classes and treats everything in it as static and immutable by default. Likewise, record classes could be sealed and have all fields read-only by default. But this then creates inconsistencies in the language where eg a field is default read-only in some contexts and not in other.

Currently, we are stuck on option one as all other options have problems too. Hopefully at some stage, some bright spark will think up another option though that allows progress in this area.