Field keyword working group notes for August 7th, 2024

[jnm2]

https://github.com/dotnet/csharplang/blob/main/meetings/working-groups/field-keyword/FK-2024-08-07.md

Agenda

Nullability analysis with the field keyword

[dersia]

did I understand this correctly, so the backing field will always be nullable no matter what the return type of the property is?

if this is the case I find it confusing and I think this will be the case for the majority of developers. by now everyone using Nullability has learned, that specifying Nullability on a type means that it can be null and not doing so means, that it (in normal circumstances) won't be null. also we have learned to initialize non-nullable properties and fields, I think it would be much nicer to allow specifying the default value for the backing field like so:
[field: DefaultValue(<const expression>)]

but maybe I understood the meeting notes wrong, in this case don't mind me 😅

[CyrusNajmabadi]

did I understand this correctly, so the backing field will always be nullable no matter what the return type of the property is?

No. It's nullable when it is safe for it to be nullable. For example, if you write your getter as get => field ?? "";

Also, note that "nullable" here only refers to 'nullable reference types'. It doesn't apply to value types. Intuitively, we allow nullable, when it makes the code more flexible, and has no impact on runtime representatino.

I think it would be much nicer to allow specifying the default value for the backing field like so:

You can always specify the default value of teh backing field. Just write:

X Prop { ... } = defaultValue;

but maybe I understood the meeting notes wrong, in this case don't mind me

Def a misunderstanding. But always feel free to get clarification on things.

[jnm2]

@dersia Not quite, only in certain cases. The meeting notes refer to accepting the null-resilient getters part of the proposal in the reviewed document. In the currently considered form:

For a property of a non-nullable, non-value type, if no nullability attributes are applied manually to the backing field with [field: ...], then the backing field will be nullable if this does not cause any nullability warnings in the property getter.

This enables core cases like the following to be written without a compiler warning that the field-backed non-nullable property must be initialized in the constructor:

public Foo LazilyInitialized => field ??= new();

[dersia]

thanks for the clarification. really looking forward to this feature (I was hoping to get it with C#13) 😊