[Proposal]: Nullable reference type checks should not be performed on members of abstract class

[SetTrend]

FEATURE_NAME

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary / Motivation

Currently, nullable reference checks are performed on non-private properties/fields of abstract classes.

Abstract classes, however, cannot be instantiated. Instead, a derived class must be implemented to get the abstract class to life.

So, I propose to omit corresponding nullable reference checks from the constructor of abstract classes and, instead, raise them to occur on constructors of derived, non-abstract, implementing classes:

Currently, it is required to assign redundant dummy values to such kind of properties/fields, which is cumbersome depending on the type of object to create. It doesn't add meaning to the code and bloats the result.

[Phantonia]

I kind of see your point, but I disagree. In my opinion, each field should be private. Every class should ensure itself that instances are in a valid state. It's also quite telling that you can't even assign readonly field of the base class in a sub class's constructor.
The better way would be assigning the field in the base class's constructor and making it a parameter.

[theunrepentantgeek]

This is easy to test - here's a SharpLab example.

Assume this class definition:

public class Container 
{
    private readonly string _name;    
    public string Name { get => _name; }   
}

Using the field directly, Console.WriteLine(_name); compiles to this in release mode:

    L0004: mov rcx, [rcx+8]
    L0008: call System.Console.WriteLine(System.String)

Using the property, Console.WriteLine(Name) compiles to this:

    L0004: mov rcx, [rcx+8]
    L0008: call System.Console.WriteLine(System.String)

Yup. This shows that trivial property setters are definitely elided in release builds.

[SetTrend]

Nonetheless:

public class Container 
{
    private int _x;
    private int _y { get; set; }
    
    public Container()
    {
        _x=1;
        _y=2;
    }
}

... yields (in full length):

Container..ctor()
    L0000: mov dword ptr [rcx+8], 1
    L0007: mov dword ptr [rcx+0xc], 2
    L000e: ret

Container.get__y()
    L0000: mov eax, [rcx+0xc]
    L0003: ret

Container.set__y(Int32)
    L0000: mov [rcx+0xc], edx
    L0003: ret

... which is 7 opcodes compared to 3 (a surplus of 150% percent).

It cannot be precluded that calls to get__y()/set__y(Int32) will be performed under certain circumstances. Frankly, the examples given are very trivial.

[theunrepentantgeek]

So?

A micro-optimization that saves a handful of opcodes might (just might, if we ignore CPU caching) save a nanosecond or two.

You'd need an astonishingly large number of them to have any detectable effect - and as soon as you start interacting with anything out of thread (another thread, a system call, another process, network access to a database or another server) statistical variances in timing of those will completely dominate the benchmark results.

[huoyaoyuan]

I prefer fields over properties because they yield a faster compile result.

Talking about "fast" at this level makes very wrong sense. This is a common mistake for ones casual about performance. If non-virtual auto property produces worse code, it should be treated as a compiler bug.

... which is 7 opcodes compared to 3 (a surplus of 150% percent).

Sharplab forces compilation of get__y and set__y to show them. In real world they will be always inlined and never compiled as separated methods.

Performance difference on these can be much smaller than you think. Don't let wrong sense of performance disturb the design.

[SetTrend]

@theunrepentantgeek : You seem to forget IoT devices. Not all of them allow to spend loads of memory unnecessarily. And you seem to ignore repetitive tasks, like loops.

Services are permanently running loops all the time, thereby burdening machine resources. In contrast to your assumption, hundreds of software packages are permanently competing for resources on a machine.

@huoyaoyuan : Thank you for your valuable comment. I'm going to check this later.

[huoyaoyuan]

This is covered by required properties. The abstract class will be able to require derived class to initialize the member, and it can be safely treated non-null.

[SetTrend]

My off-topic proposal is just to take the burdon of always being required to write { get; set; } for a thing that's compiled into a field anyway.

[SetTrend]

A private property isn't a contract, it's implementation.

[huoyaoyuan]

I never see usage of private property in guideline-followed codebases.

[SetTrend]

So, you're saying "we never did that before" - and that this should be the reason to thwart the improvement?

[333fred]

Fwiw, Kotlin actually did this: there are no fields. Everything is a property. However, it would be a massive breaking change for C# to change that now.

[huoyaoyuan]

I'm going to terminate the off-topic and focus on the original question.

Nullability and abstract are contract, while fields are implementation.

Abstract classes, however, cannot be instantiated. Instead, a derived class must be implemented to get the abstract class to life.

Yes. It must be derived. However, there's no forcing about the derived class must initialize the non-null fields. Current contract is the base class constructor must initialize everything properly. Modifying the contract will require additional annotations, which is required fields/properties.
The only way currently to force derived class to pass initialization value is via constructor.

[SetTrend]

Yes, I created a separate proposal for the off-topic as I share your opinion.

However, there's no forcing about the derived class must initialize the non-null fields.

That's the current design flaw. And that's the core of my suggestion: It must be forced that a class deriving from an abstract class will make sure all properties not initialized by the abstract base class will be initialized.

[huoyaoyuan]

not initialized by the abstract base

Derived class can't see the implementation code in base class (for cross assembly scenario), so there must be a way to annotate that, which is required fields/properties.

[SetTrend]

Absolutely, we don't disagree here. As I wrote before, your proposal is great, and I agree with it.

It just should be automatic, not explicit. There's no need to manually annotate the inevitable. The compiler may annotate the abstract class's non-private properties (fields) automatically when they are not initialized by the abstract class itself.

[huoyaoyuan]

It just should be automatic, not explicit.

2 points:
There must be a way to do it. The language team is just starting the designing phase.
The general design flavor of C# is to avoid inferring public contract from implementation to prevent accidental break. So there could probably be an IDE helper to quickly do the annotation.

[SetTrend]

Sure. Sounds great to me.