[Proposal] Introduce 'static' as a similar keyword to 'this'

[Patton97]

Summary

Code should be able to qualify access to the current type's static members via the keyword static, in the same way it can qualify access to the current type's instance members via the keyword this.

---

Motivation

The primary motivation is to enable a compromise in dev teams' coding guidelines. There currently exist 2 sides:

1. Static members should be fully qualified with the declaring type name.
2. Static members should not be fully qualified.

Both sides have good arguments.

Fully qualifying your static member immediately makes it clear to the reader that this member is in fact static; it also makes it somewhat clear that this member is a member of the current type (if the reader is paying attention). However, if the type's name is long, this can begin to largely clutter the code, especially if many static members are being accessed in the same area of code.

Not fully qualifying your static members avoids this clutter, but makes it ambiguous to the reader as to whether the member being qualified is a static or instance member. This can be navigated with member name prefixes such as s_, but many coding guidelines are against this Hungarian notation style.

The official .NET Coding Conventions prescribe full qualification as the desired style.

Call static members by using the class name: ClassName.StaticMember. This practice makes code more readable by making static access clear.

The proposed syntax would strike a balance between these, by making static access clear, whilst avoiding too much clutter. Many class names go well beyond the 6 character length of static, and may have other meanings (e.g. member properties with the same/similar names as their types). The use of the static keyword in this context would be non-ambiguous, and nicely consistent throughout your class.

---

Syntax

The syntax for qualifying a static member would appear as follows (alongside the existing syntax)

public class DogFactory
{
    private static IReadOnlyList<string> possibleDogNames = new List<string>() { "Pippin", "Sheba", "Lacie" };
    
    private static string GetRandomDogName()
    {
        Random random = new Random();
        
        // Existing syntax (full qualification)
        int randomNumber = random.Next(0, DogFactory.possibleDogNames.Length);
        return DogFactory.possibleDogNames[randomNumber];
                
        // Existing syntax (no qualification)
        int randomNumber = random.Next(0, possibleDogNames.Length);
        return possibleDogNames[randomNumber];
        
        // Proposed syntax
        int randomNumber = random.Next(0, static.possibleDogNames.Length);
        return static.possibleDogNames[randomNumber];
    }

    public Dog Create()
    {
        return new Dog
        {
            // Existing syntax (full qualification)
            Name = DogFactory.GetRandomDogName(), 
            // Existing syntax (no qualification)
            Name = GetRandomDogName(), 
            // Proposed syntax
            Name = static.GetRandomDogName(),
        };
    }
}

---

Open Questions

The open question to me remains whether the static keyword should, in the proposed context, also be a valid qualifier when accessing static members from a derived type. The official .NET Coding Conventions seem to indicate it should not.

Don't qualify a static member defined in a base class with the name of a derived class. While that code compiles, the code readability is misleading, and the code may break in the future if you add a static member with the same name to the derived class.

I therefore currently believe that the static keyword should not be a valid qualifier when accessing static members from a derived type. This ruling would allow even stronger enforcement of the official conventions, as teams could enforce static as the desired qualifier for the current type's static members, but the full type name as the desired qualifier for any other type's static members (be they derived or not).

The only other solution I can think of is to also allow base.static, but that feels rather ham-fisted, and out of canter with the rest of the language.

---

Additional Notes

I found a very similar (unanswered) suggestion here, which suggested class instead of static, but seems to have gone stale. I've created this new thread both to refresh the discussion and so that I can provide a fuller proposal than the original thread.

This is the first post I've made here. I've tried to follow the format of some other proposals, but if there's anything missing just let me know.