Nullable Value Type property enhancements.

[franchyd]

Summary

Introduce syntax for properties that allow a nullable setter/init and a non-nullable getter for value types. This enables clean patterns where a property may accept or start as null but will always return a value.

Motivation

A common pattern in real-world development is to have a property that accept null (e.g., during deserialization, configuration, or delayed assignment), but never return null to consumers.
This is easily achieved with Reference types, but for value types, this requires verbose manual backing fields and a function:

private int? _value;

public int Value
{
    get => _value ?? throw new InvalidOperationException("Not initialized.");
    set => _value = value;
}
public void ClearValue() => _value = null;

Proposed Syntax

// Auto-Property
public int Value
{
    get => field ?? throw new InvalidOperationException("field not set.");
    set nullable;
}
// Auto-Property
public float Value
{
    get => field ??= ExpensiveLazyInitFunction();
    init nullable;
}
private JsonCache json;
// Manual implementations
public double Value
{
    get => json.GetOrDefault("DoubleValue", 0.0);
    set nullable => value.HasValue ? json.Set("DoubleValue", value.Value) : json.Clear("DoubleValue");
}

Semantics

If using an auto-property, the backing field is nullable
An explicit getter implementation is always required (as otherwise it could return null).

Pros

• Clean, concise syntax for a common pattern
• Enables deferred-initialization scenarios without multiple fields/functions.

Cons

• requires looking at set/init declaration to determine backing field type.

Further thoughts

Should a nullable set be able to implement a non-nullable set from an interface:

interface IInterfaceWithProperty
{
    int Value { get; set; }
}
class ClassWIthProperty : IInterfaceWithProperty
{
    public int Value
    {
        get => field ?? throw new InvalidOperationException("field not set.");
        set nullable;
    }
}

It would be on par with NRTs capabilities to do so, however as NVT's are different runtime types than non-nullable value types it would be a different signature and would require a hidden non-nullable proxy "set" to be generated by the compiler.

How do you declare a nullable backing field when you don't want a nullable set.

// Auto-Property
public short Value
{
    get => field ??= ExpensiveLazyInitFunction();
    set; // non nullable setter
    init nullable;
}

Its a bit against current patterns to have both a setter and an init accessor. Alternatively in this scenario(or a getter only scenario) the compiler could infer the nullability of the backing field from the getter’s implementation. However this is also counter to current language concepts in that slight changes to the getter can transform the type of the backing field.

[timcassell]

#9272 (comment)

[HaloFour]

I think that specifically applies to nullable reference types, not nullable value types.

[timcassell]

Perhaps, but I see no reason why the compiler couldn't infer the backing type for nullable value types using the same mechanism, as long as it's not an unconstrained generic.

[HaloFour]

It's possible, but I kind of doubt it given that it would impact the actual type of the backing field and having the layout of the type shift unexpectedly feels undesirable. There's also the issue that since you can't reference the backing field directly and arbitrarily that you really would have no mechanism to "reset" it to null.

[franchyd]

This would however maybe be a solution to a getter only scenario which I now realize I didn’t cover.

[timcassell]

Oh I didn't fully get the proposal, you want a non-nullable getter with a nullable setter. I guess that's a whole different feature request itself. Kind of weird, though, tbh.