Proposal: Improve the constraint support for delegate constraints to enable generic event subscription

[taori]

As specified here dotnet/roslyn#28835 i am unhappy with the current usefulness of the delegate constraint. While it does solve some scenarios, which were not possible yet, i think there is one important scenario where there is a big usability gap still.

Currently there is no way for this to compile:

public class MyClass<TDelegate> : IMyInterface<TDelegate> where TDelegate : Delegate
{
        // COMPILER COMPLAINS HERE about OnEvent needing to be a Delegate, which it kind of has to be, because of the constraint?
	public event TDelegate OnEvent;

	/// <inheritdoc />
	public void Add(TDelegate handler)
	{
		throw new NotImplementedException();
	}

	/// <inheritdoc />
	public void Remove(TDelegate handler)
	{
		throw new NotImplementedException();
	}
}

public interface IMyInterface<TDelegate> where TDelegate : Delegate
{
        // event TDelegate OnEvent;
	void Add(TDelegate handler);
	void Remove(TDelegate handler);
}

Being unable to subscribe to that event, nor even being able to declare the event in a class is quite a pitfall in the usefulness of the delegate constraint.

[HaloFour]

        // COMPILER COMPLAINS HERE about OnEvent needing to be a Delegate, which it kind of has to be, because of the constraint?
	private event TDelegate OnEvent;

Technically not. The CLR will allow TDelegate to be System.Delegate, or System.MulticastDelegate, neither of which are permitted to be declared as events in C#.

The proposal that was implemented only intended to remove the language restriction preventing you from being able to use System.Delegate as a constraint, something that the CLR has always supported. But any functionality beyond that would require further design and would either require CLR changes or would lack CLR enforcement. This is also why the team doesn't permit the delegate keyword as the constraint, it leaves that open to further possibilities.

I don't know what your actual use case is or if the example above is representative. If the event is private then there isn't a great deal of benefit in being able to declare it as an event vs. just a field. The biggest advantage is the thread-safe subscription and unsubscription, which is something you can implement yourself pretty easily.

[taori]

I don't know what your actual use case is or if the example above is representative. If the event is private then there isn't a great deal of benefit in being able to declare it as an event vs. just a field. The biggest advantage is the thread-safe subscription and unsubscription, which is something you can implement yourself pretty easily.

You're correct. If it were not public it would not be as useful, however that is just the problem where i noticed it, that the code i am trying to develop does not even compile that way.

However i've used code like delegate void MyEventHandler(object sender, object arg); in the past to pass on data with events. Being able to stay generic with events too, seems only rational.

The way it is now, i cannot even declare the event, so i am not able to raise the delegate, since the class does not compile. That's a big problem imo.