Fix the delegate type system

[Banyc]

Background and Motivation

I want to clean up all the delegates that are previously assigned to a timer's Elapsed event. I don't want it to fire the old delegates that have had the old parameters. I want the timer to fire the newest delegate with the newest parameters.

From this small perspective, we can find out that there is a pitfall in the delegate type system. It might be a C# language design flaw. Based on the contributor of dotnet/runtime, it is about the ability to modify the contract of delegate and event. I hope the contributors of both repositories can have a discussion of this issue since I, as a common user, have not dived into the .NET platform.

Proposed API

Please make EventHandler as a IList that could be Clear(), Add(), ...

Just make something like:

public class EventHandler : IList<Delegate>

or

public class EventHandler : List<Delegate>

Usage Examples

timer.Elapsed.Clear();

Alternative Designs

There are a lot of complaints about this issue. One of the examples:

• https://stackoverflow.com/questions/91778/how-to-remove-all-event-handlers-from-an-event

It is not easy to remember/keep track of the old delegates that have been assigned to an event handler. Make Clear() method could make life tons' better.

As contributor stated here, it could be solved by adding clear accessor to EventHandler. But the contributor here believes the ability to modify the contract of delegate and event is the key to fix similar issues once and for all. I believe a more inclusive solution can address more problems in the future.

Risks

Might take some time to implement and test, or even refactor all the runtime library. (I am not quite sure about that since I am just a usual user).

Relative issues

• [Proposal]: make EventHandler as a IList #4535
• [Proposal]: make EventHandler as a IList runtime#49595

[CyrusNajmabadi]

I don't believe this is something related to the language. You might want to take this to dotnet/runtime. Would you like me to move it there?

[Banyc]

I don't know... Thanks for the advice and the fast reply! It might be a good idea!

[huoyaoyuan]

Updating the type system requires big work in both runtime and language.

[huoyaoyuan]

In fact, I did have some fragments of how to update the delegate type system, but didn't arrange them. In brief, my opinion is to drop multicast completely, and force multicast usage to use List<delegate>.

[HaloFour]

As mentioned in #4535, delegates are immutable. When you add or remove a delegate from the event you're actually replacing the event's backing field with a new delegate instance. There is already a means in the language to "clear" that delegate field so that it points to no subscribers: set it to null:

protected void ClearMyEvent() {
    this.MyEvent = null;
}

See here: Example

[CyrusNajmabadi]

Great idea. Def raise that with runtime!

[HaloFour]

@CyrusNajmabadi

Great idea. Def raise that with runtime!

Done and done: dotnet/runtime#49619

[qrli]

Why having to implement explicitly? Why not simply:

public class C {
    [ThreadSafe] // by attribute or whatever means
    public event EventHandler MyEvent; // compiler generates safe field access for me
}

[huoyaoyuan]

The generated access should be always thread safe from the start.

[canton7]

I might have been unclear.

This is thread-safe:

public event EventHandler foo;

This is not thread-safe:

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