Proposal: Events as Values

[YaakovDavis]

Motivation

In FRP, FP, RX, etc. styles of programming, it's desirable to treat events as values, being passable as args, returned, held in variables, etc.
Currently there's no built-in way to do it, and various custom solutions have been developed by the community, relying on code generation, reflection, etc.

Proposal

I propose the following additions to the language & standard library, to enable this goal:

• An mscorlib interface representing the subscription operations enabled by events (add, remove)
• Reuse of the event keyword, to allow instantiating event expressions

The interface will look like this:

namespace System
{
    public interface IEvent<T>
    {
        void Subscribe(T handler);
        void Unsubscribe(T handler);
    }
}

Usage example:

class DataSource
{
    public event Action<string> DataRecieved;
}

class Program
{
    void Foo()
    {
        var dataSource = new DataSource();

        //the compiler translates the following to an instantiation of IEvent<Action<string>>
        var dataReceived = event(dataSource.DataRecieved); 

        dataReceived.Subscribe(OnDataReceived);
        dataReceived.Unsubscribe(OnDataReceived);
    }

    void OnDataReceived(string data)
    {
       //...
    }
}

Implementation

In the above example, the compiler will generate a class implementing IEvent<Action<string>> that has a field of type DataSource to hold the dataSource instance.

The expression event(dataSource.DataReceived) is translated to an instantiation of this generated class. Calling Subscribe/Unsubscribe simply forwards the operations to the event.

Example implementation:

[CompilerGenerated]
class DataSource_DataReceivedEvent : IEvent<Action<string>>
{
   DataSource targetInstance;

   public DataSource_DataReceivedEvent(DataSource targetInstance)
   {
       this.targetInstance = targetInstance;
   }
  
   public void Subscribe(Action<string> handler) => targetInstance.DataReceived += handler;
   public void Unsubscribe(Action<string> handler) => targetInstance.DataReceived -= handler;
}

Further notes

• Delegates with return types are supported as well.
• The compiler should be smart enough to share implementations, i.e. one generated class per event per containing type, per calling assembly.
• Multiple implementations can be generated in multiple assemblies; they'll do the same, while being independent of each other.

[svick]

I do think some form of first-class support for events should be in C#, but:

1. Since this is basically just about generating some code, maybe this could be implemented as a code generator (Champion "Replace/original and code generation extensions" #107)? Doing that would mean the event() syntax couldn't be used, but I don't think that's a big issue.

2. I don't think Raise should be part of the interface. For field-like events, raising them is limited to the private scope. Other events cannot be raised at all.

   So, if I use event() on an event from some other type, Raise should not exist (and probably cannot be implemented without reflection, if at all). If I use event() on an event from this type and return it, I'm allowing others to raise the event, even if I don't want to do that.

3. This proposal is unlike anything else in C#. Is there some way to make it more consistent with the rest of C#?

[YaakovDavis]

@svick

1. Code generation is better than nothing, once and if it becomes available. However, this approach will prevent implementing general-purpose libs that deal with events. I think that the concept of event is important enough to have a standard interface representation of it.
   Also, how would you instantiate the event representation without a syntactic support?

2. Re. Raise: I agree; will update the proposal.

3. This proposal is unlike anything else in C#

   Can you elaborate? In what way?

[svick]

I think that the concept of event is important enough to have a standard interface representation of it.

In that case, the interface could still be part of the standard library, even if there was no special support for implementing it in the language. (And the implementation of that interface would be done by the code generator.)

how would you instantiate the event representation without a syntactic support?

That depends on how exactly will code generation end up looking. But I think at least something like this should be possible (if not something even better):

[EventClass(typeof(DataSource), nameof(DataSource.DataReceived))]
class DataSource_DataReceivedEvent {}

…

new DataSource_DataReceivedEvent(dataSource).Subscribe(OnDataReceived);

This proposal is definitely prettier and more convenient than the above code, but maybe the above would be good enough?

This proposal is unlike anything else in C#

Can you elaborate? In what way?

In that there is currently no keyword in C# that generates a class implementing some interface and returns an instance of that class. Obviously every language proposal is about adding something new to the language, but I think that preferably, it should be done in a way that fits with the rest of the language, and I'm not sure this approach does.

Maybe something that already exists in C#/.Net could be expanded and improved for this purpose (EventInfo?). Or maybe this should be part of a more comprehensive reflection overhaul (add IProperty, something like https://github.com/dotnet/corefx/issues/15453 for enums, etc.).

But this is more of a vague complaint or a gut feeling, not a concrete complaint.

[YaakovDavis]

new DataSource_DataReceivedEvent(dataSource) ...

I wouldn't call it "first-class support for events"..
I do like my proposal better :)

there is currently no keyword in C# that generates a class implementing some interface and returns an instance of that class

yield does exactly that; the compiler generates an implementation of IEnumerable<T>. Calling the method returning the IEnumerable<T> generates an instance of the generated type.

Also, every time you use delegates/lambdas (especially with closures), a class is generated & instantiated:

var x = 15;
Func<int> a = () => x;

The compiler will generate a class to hold x, and place an instantiation of it in the method body.

[scottdorman]

This idea sort of feels like what we have now with IProgress<T> and Progress<T>. If I need to report progress back to the client (especially from async methods), I can instantiate an instance of Progress<T> in the client code and pass that instance to the async method. In the async method, I can then call Report on the passed in instance, which raises the appropriate event which the client is listening for and reports status.

[quinmars]

A similar proposal was made by Thomas Levesque here: https://github.com/dotnet/roslyn/issues/298

I’m also convinced that there needs to be an (easier) way to pass events as method arguments. It makes Rx, sometimes described as Linq for events, less appealing as it could be. For example if you want to subscribe an event and filter it, you have to write horrible long code:

Observable.FromEventPattern<PropertyChangedEventHandler, PropertyChangedEventArgs>(
                                h => vm.PropertyChanged += h,
                                h => vm.PropertyChanged -= h)
                            .Where(t => t.EventArgs.PropertyName == "Employee")
                            .Subscribe(_ => DoSomething());

This could then be reduced with the proposal of Thomas to something like this:

vm.PropertyChanged
                .ToObservable()
                .Where((o, e) => e.PropertyName == "Employee")
                .Subscribe(_ => DoSomething());

Both Thomas’ EventDescriptor and Yaakov’s IEvent define an interface which allows an observer to subscribe to a push notification provider. We already have an Interface for exactly this job. It’s called IObservable. Hence my preferred solution would be, that an Event automatically converts to something that implements IObservable. The example above reduces then to:

vm.PropertyChanged
                .Where((o, e) => e.PropertyName == "Employee")
                .Subscribe(_ => DoSomething());

Then “Linq for events” will become as comfortable as Linq for objects is since a long time.

[HaloFour]

@quinmars

I like it, conceptually. It also has the benefit of reusing an interface that has existed in the BCL for the last seven years, so no runtime changes are required.

I do have the following concerns:

1. Seems MS forgot that they invented Rx so I'm not expecting much traction around IObservable<T>, despite how awesome it is.
2. How would the compiler handle non-EventHandler<T> events? Should it "duck-type" EventHandler<T>-like delegates, e.g. MouseEventHandler? What about events that don't follow the convention at all?

[YaakovDavis]

@quinmars @HaloFour
Although related, events are observables are different:

• Event handlers can return values while observers can't.
• Events work for generic delegate types, while observables are limited to a single value.
• Observables can be "completed" while events can't.
• IEvents allow subscription/unsubscription using a single instance. Observers require maintaining a separate instance for the observer in order to dispose it, ie. unsubscribe. This shows why events under this proposal are real values, while they aren't with observables.
  It has an impact on the kind of libraries that can be built on top of events, and on the way one may architect an app.

To work at the language level, the feature must support the core language capabilities, not just a specific pattern (e.g. EventHandler<T>).
Once first-class event support is implemented, we can add conversion methods to existing RX, etc. libraries, that convert from IEvent<TDelegate> to IObservable<TValue>, etc.
Also, It'll be just a matter of time before someone implements Linq for real events.

[quinmars]

@HaloFour

How would the compiler handle non-EventHandler<T> events? Should it "duck-type" EventHandler<T>-like delegates, e.g. MouseEventHandler? What about events that don't follow the convention at all?

Here is how thought the compiler could do the conversion:

public delegate void EvHandler1(T val);

would obviously turn into IObservable<T>.

public delegate void EvHandler2(T1 val1, T2 val2);

into IObservable<(T1 val1, T2 val2)>. Same for 3 or more arguments.

public delegate void EvHandler3();

is a little bit problematic. The natrual solution would be IObservable<System.Reactive.Unit> but Unit is not part of the BCL. Maybe EventArgs could be used as an empty value.

Unfortunately, there are, however, some possible delegate types that wouldn't work, for example:

delegate void EvHandler4(ref int e);
delegate void EvHandler5(out int e);
delegate void EvHandler6(in int e);

So it seems that my idea is not general applicable.

Seems MS forgot that they invented Rx so I'm not expecting much traction around IObservable, despite how awesome it is.

It would also help with TPL programming, because events would become awaitable:

var d = new Dialog();
d.Show();
(var o, var e) = await d.Closed.Take(1); // <- Closed is an event
this.Save(e.FileName);

@YaakovDavis

I cannot follow all your points, but I also don't think anymore that my idea is generally applicateably (see above). But still I'd prefer the Subscribe and Unsubscribe methods of IEvent, EventDescriptor or ... to be renamed to something that doesn't clash with IObservable. Just to not finally close that door. Add and Remove would be a natural choice.