Proposal: Allow initializing existing static fields and properties in the class body

[bawNg]

C# only allows initializing static fields and properties in the class body when they are defined. If defined in a base class, which is common when reusing static level logic with recursive generics, the derived class is forced to use a static constructor to initialize the field or property.

If feasible to parse, it would make sense for C# to allow initializing existing static fields and properties in the class body and have the compiler move the initialization into the static constructor just like it would if it was on the right of a definition.

This would allow derived classes to configure their base class cleanly, including in certain cases where attributes are not suitable due to their compile-time limitations.

// Current syntax when using recursive generics
public class Client : ReliableClient<Client, Protocol.Type, Protocol.Flag>
{
    static Client()
    {
        AckType = Protocol.Type.Ack;
        ReliableFlag = Protocol.Flag.Reliable;
        ProtocolVersion = 1;
    }
}

// Proposed syntax when using recursive generics
public class Client : ReliableClient<Client, Protocol.Type, Protocol.Flag>
{
    AckType = Protocol.Type.Ack;
    ReliableFlag = Protocol.Flag.Reliable;
    ProtocolVersion = 1;
}

// Current syntax when using partials with code generation
[Mixin(typeof(BaseMessage))]
public partial struct PingMessage
{
    static PingMessage()
    {
        RequestType = MessageTypes.Ping;
        ResponseType = MessageTypes.Pong;
    }
}

// Proposed syntax when using partials with code generation
[Mixin(typeof(BaseMessage))]
public partial struct PingMessage
{
    RequestType = MessageTypes.Ping;
    ResponseType = MessageTypes.Pong;
}

[ufcpp]

maybe related to records (primary constructor)

[jnm2]

The current limitation clearly shows the reality of the situation: you're setting shared static fields. The field state is shared with any other class which derives from that base class, as well as direct field access via ReliableClient<Protocol.Type, Protocol.Flag>.AckType.

It's a bit surprising for the type initializer of one static class to set the state of another static class. Static state isn't inherited.

[bawNg]

I've updated the example to actually use recursive generics as that would be the most appropriate use case.

[The-Futurist]

@bawNg - What if we changed your example to look like this:

// Current syntax
public class ClientA : ReliableClient<Client, Protocol.Type, Protocol.Flag>
{
    static ClientA()
    {
        AckType = Protocol.Type.Ack;
        ReliableFlag = Protocol.Flag.Reliable;
        ProtocolVersion = 1;
    }
}

public class ClientB : ReliableClient<Client, Protocol.Type, Protocol.Flag>
{
    static ClientB()
    {
        AckType = Protocol.Type.Nack;
        ReliableFlag = Protocol.Flag.Unreliable;
        ProtocolVersion = 5;
    }
}

Can you see how this is bad?

[bawNg]

@Korporal - If you don't pass the derived class to the base, the example is no longer correctly implemented with recursive generics, which means you can't have multiple derived classes as they would share the static state in the base class.

I don't think repeating the class name for the static constructor makes a real difference in protecting against badly implemented generics, compared to just having the statements in the class body. Protection against badly implemented derived classes should really be enforced with better recursive generic constraints in the base class.

I make extensive use of recursive generics to emulate inheritance of static fields in C#. The alternative and only option for structs is partials with code generation. This proposed syntax change would also allow setting fields and properties defined in generated partials without having to use static constructors.

[The-Futurist]

@bawNg - If your design strategy is such that you are only allowed (though how you police this I do not know) to create one class that inherits some base class then I question the wisdom of even using inheritance here.

[bawNg]

@Korporal In most cases, you would want to be able to create multiple derived classes, which is why you would use recursive generics correctly as shown in my example. That allows any number of classes to inherit and make use of some base class which stores state specific to the derived class.

[The-Futurist]

@bawNg - Perhaps I'm missing something here. Earlier you wrote

"you can't have multiple derived classes as they would share the static state in the base class."

and just now you then wrote

"In most cases, you would want to be able to create multiple derived classes".

[bawNg]

@Korporal I was referring to your changed example which does not implement recursive generics.

If you don't pass the derived class to the base, the example is no longer correctly implemented with recursive generics, which means you can't have multiple derived classes as they would share the static state in the base class.

[The-Futurist]

@bawNg

I was referring to your changed example which does not implement recursive generics.

Yet my example wasn't a change and is using "recursive generics" because it was a copy/paste of your own example code titled (by you) "current syntax when using recursive generics".

[bawNg]

@Korporal If you intended to use recursive generics in your example, the Client type you are passing to the base class must be a typo, as it should be ClientA and ClientB respectively. That would make it recursive and ensure that the static state be specific to the derived class as intended, instead of being shared between the two when passing some other Client class as the first generic argument.

[The-Futurist]

@bawNg - Ahh OK now I see and yes that was a typo. Why not include an example of the ReliableClient class that will help me appreciate your example better.