Why is the implementation of events in C# not using a weak event pattern by default?

Question

This question may lead to speculative answers but I presume there's a well thought design decision behind the implementation of event in c#.

The event pattern in c# keeps the subscriber alive as long as the publisher of the event is alive. Thus, if you don't unsubscribe, you're leaking memory (well, not really leaking - but memory remains occupied unnecessarily).

If I want to prevent this, I can unsubscribe from events or implement a weak event pattern as proposed at MSDN.

With the event pattern causing so many problems (for beginners?), the question is: why was the decision made that the publisher keeps a strong reference to the subscriber, instead of making them independent or allowing developers to explicitly have a strong or weak modifier?

There are already a couple of questions here about this topic and the answers sound reasonable, but none really answers why it is like it is.

Answer 1

One reason certainly is performance. GC handles (which power all of the "exotic" references such as WeakReference) come with a performance cost. Weak events are slower than "strong" events since they require a GC handle. A strong event is implemented (by default) by an instance field storing a delegate. This is just an ordinary managed reference as cheap as any other reference.

Events are supposed to be a very general mechanism. They are not just meant for UI scenarios in which you have maybe a few dozen event handlers. It is not a wise idea to bake a lot of complexity and performance cost into such a basic language feature.

There also is a semantic difference and non-determinism that would be caused by weak references. If you hook up () => LaunchMissiles() to some event you might find the missiles to be launched just sometimes. Other times the GC has already taken away the handler. This could be solved with dependent handles which introduce yet another level of complexity.

Note, that you can implement weak events yourself transparently to the subscriber. Events are like properties in the sense that they are mere metadata and conventions based around the add and remove accessor methods. So this is (just) a question about the defaults that the .NET languages chose. This is not a design question of the CLR.

I personally find it rare that the strong referencing nature of events is a problem. Often, events are hooked up between objects that have the same or very similar lifetime. For example you can hook up events all you want in the context of an HTTP request in ASP.NET because everything will be eligible for collection when the request has ended. Any leaks are bounded in size and short lived.