Nullable reference types and events

[thomaslevesque]

I'm trying to get my head around something... With nullable context enabled, if I declare an event like this:

public event EventHandler Foo;

I get a warning because it's not initialized, which makes sense. But I don't have any relevant value to initialize it with, so I'd rather make it nullable. But if I do this:

public event EventHandler? Foo;

It quells the warning, but it seems to imply that null would be a valid handler for this event, even though it's not.

I guess I could apply different nullability to the event itself (not nullable) and the backing field (nullable). Something like this:

private EventHandler? _foo;
public event EventHandler Foo
{
    add { _foo += value; }
    remove { _foo -= value; }
}

But it's a shame to have to do this, I'd rather keep using field-like events. The snippet above is annoying to write, and doesn't even do the same thing as a field-like event (which is a bit more complex to take care of thread safety).

So what's the recommended way to declare events with nullability enabled?

---

It's probably too late now, but I think it would have been nice if field-like events worked like my snippet above:

• The event itself is non-nullable, so when adding/removing a handler, a non-null value is required
• The field is nullable, so when raising the event, it must be checked for null first

class Test
{
    public event EventHandler Foo;

    private void RaiseFoo()
    {
        // Foo refers to the field here, which is nullable
        Foo?.Invoke(this, EventArgs.Empty);
    }
}

var t = new Test();
// Foo refers to the event here, which is not nullable
t.Foo += (sender, args) => ...

[thomaslevesque]

It quells the warning, but it seems to imply that null would be a valid handler for this event, even though it's not.

I guess it doesn't really matter, since even when the event is declared as not nullable, no warning is emitted for Foo += null... Is this expected?

[svick]

Is there a particular reason why you want to forbid null handlers, considering Foo += null is a no-op?

[thomaslevesque]

I guess not... It's just that it doesn't feel right.

[HaloFour]

t.Foo += null is not a no-op. The add accessor is invoked. The default implementation of the accessor method does gracefully handle null by virtue of the fact that Delegate.Combine ignores null. But a custom handler that does something with the delegate and doesn't handle the possibility of it being null could certainly result in an NRE.

[canton7]

I think the compiler suggesting that events should be nullable is a good thing. It reminds you to invoke them in a null-safe way.

However it also lets people who want to follow this pattern do so:

public event EventHandler Foo = delegate { };

Also:

private EventHandler? _foo;
public event EventHandler Foo
{
    add { _foo += value; }
    remove { _foo -= value; }
}

Watch out: this isn't thread-safe. (You probably knew that already, but others reading this might not.)

[svick]

@HaloFour I understood this issue to be specifically about field-like events. If you're writing custom accessors, there doesn't seem to be any issue with nullability.

[HaloFour]

@svick

I read the OP as NRTs don't currently handle field-like events well, in that either you declare it as non-nullable and the compiler complains that you're not initializing it (which makes no sense), or you declare it as nullable and the accessors don't warn when passing null.

Either way, to shut up the compiler you're forced to adorn all events as nullable, and that seems silly.

[thomaslevesque]

@svick, my issue is perfectly summarized by @HaloFour's last comment. I know I can work around it with custom accessors, but it's a pain to write correctly (if you want to account for thread safety, at least).