LDM Notes for August 14th, 2024

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-08-14.md

Agenda

• field keyword
  • field nullability
  • field in event accessor
  • Scenarios similar to set;

[TahirAhmadov]

Not that it's a huge priority, but one scenario for events is:

event EventHandler MyEvent
{
  add
  {
    field += value;
    this._component.RelatedEvent += value;
  }
  remove
  {
    field -= value;
    this._component.RelatedEvent -= value;
  }
}

[TahirAhmadov]

@jnm2 yes, the implicit private "getter" of the event would continue working just like with regular "field-like" (auto-implemented) events.
I do see how this becomes complicated, though. Basically, the compiler needs to read the add/remove body to determine if the "getter" becomes available, and it raises other questions, do we check "add" body only, etc.

[jnm2]

It would probably be the same as for properties. If field appears as a keyword in any accessor, then it's a field-backed property.

[TahirAhmadov]

To an extent, but with properties, the presence of field doesn't change the property's available accessors - you always get what you declared. With events, on the other hand, field would modify the signature and add the "getter" "automatically". Not saying it's a bad thing necessarily, but definitely an extra complication.

[CyrusNajmabadi]

I'm not sure what you mean by 'getter' wrt to an event.

[jnm2]

It's not so much a getter, as the ability to read the backing field of the event from outside the event. (Something that is not possible with property backing fields.)