Have events always be a non-null array

[WillPittenger]

Currently, events have to be declared as event DelegateType? evt if you enable the nullable features. Even without nullable, users had to fire the event as shown below:

if(evt != null)
  evt(parameters);

C# now allow this syntax, but it's still less than ideal:

evt?.Invoke(parameters);

But imagine this syntax:

evt(parameters);

If this were implement, the compiler would actually generate one of the above. Furthermore, events could never possibly be null. Note: for backwards compatibility, the compiler would ignore the ? that extisting versions of C# require. This might be with a compatibility warning suggesting a change to the newer syntax.

[HaloFour]

Events aren't an array, they are a multicast delegate. The design where they are null when they have no targets is intentional, and it allows the class to short-circuit work if it has no subscribers.

[HaloFour]

What you suggested is already valid syntax. It invokes the delegate as it would in any other case.

[WillPittenger]

An if there are no subscribers? What happens then?

[ufcpp]

Action a = () => { };

Action? multicast = null;

multicast += a;

Console.WriteLine(multicast is null); // false

multicast -= a;

Console.WriteLine(multicast is null); // true

[HaloFour]

It will throw a NullReferenceException, as the delegate is null. That's the case with any delegate, as it's impossible to have a reference to a delegate instance that has no subscribers.

[WillPittenger]

Which is why I suggested the compiler would generate the code I suggested.

[WillPittenger]

I'm told some developers use evt = null. That could evaluate to something like evt.Clear(). I don't the internal structure. So I made something up.

[HaloFour]

Delegates are immutable.

[WillPittenger]

So? I'm just trying to suggest how evt = null might be implemented.

[HaloFour]

It can't be implemented that way. C# events are based on multicast delegates, and multicast delegates are immutable and cannot have an empty target. Even if a Clear method existed, it would have to return null, which would have to be assigned to the backing field of the event.

I get the point is to suggest a different implementation altogether, but after 21 years I'd suggest that the ship has sailed.

[CyrusNajmabadi]

I think the challenge here, more than anything, would be the change in semantics. A lot of code has been written in the last 25 years that depends on the semantics of events and delegates. Changing that will likely break code that depended on things working a particular way.

[HaloFour]

I wonder how often people rely on invoking the event throwing if it's null. The null check itself, sure, I've relied on that myself to avoid doing work when there are no subscribers. But actually depending on the exception seems a bit of a stretch. I could see the value in having a simple null-safe way to fire the event.

I know this has been answered before, but does the language/runtime offer anything in the form of a guarantee that the event delegate can't mutate out from under you between the null check and invocation? The common pattern of checking and then invoking the mutable field has always left me feeling a tad concerned.

[CyrusNajmabadi]

There is no guarantee, and that is a race. That's why the ide suggests that you do ?.Invoke if it sees you doing that. The latter form is race free.

[HaloFour]

I seem to recall reading/hearing that the runtime would recognize the pattern and protect it through a cached read, but that was a long time ago. I don't think I've written much event-based code since the null propagation operator had been added to the language.