Proposal: allow events as method parameters

[LWChris]

Currently, events aren't first-class citizens and can only ever be used on the LHS of an += or -= expression. However, that makes delegating the possibility to add or remove handlers to a different place in the program a bit cumbersome.

Take Rx.NET Observable.FromEventPattern<TDelegate, TEventArgs> as an example. Currently, it looks like this:

public static class Observable
{
    public static IObservable<EventPattern<TEventArgs>> FromEventPattern<TDelegate, TEventArgs>(Action<TDelegate> addHandler, Action<TDelegate> removeHandler)
    {
        if (addHandler == null)
        {
            throw new ArgumentNullException(nameof(addHandler));
        }

        if (removeHandler == null)
        {
            throw new ArgumentNullException(nameof(removeHandler));
        }

        return s_impl.FromEventPattern<TDelegate, TEventArgs>(addHandler, removeHandler);
    }
}

// Usage for a FileSystemWatcher fsw:
Observable.FromEventPattern<FileSystemEventHandler, FileSystemEventArgs>(h => fsw.Created += h, h => fsw.Created -= h);

My idea is to allow methods to have an event parameter. Inside the method, the parameter is treated like an event member itself, meaning it may only be used on the LHS of += or -=, or to be passed to another event parameter. This would allow for this code:

public static class Observable
{
    public static IObservable<EventPattern<TEventArgs>> FromEventPattern<TDelegate, TEventArgs>(event TDelegate evt)
    {
        return s_impl.FromEventPattern<TDelegate, TEventArgs>(h => evt += h, h => evt -= h);
    }
}

// Usage:
Observable.FromEventPattern<FileSystemEventHandler, FileSystemEventArgs>(fsw.Created);

It basically enables you to push lambda creation further down into a centralized location, rather than requiring it at the highest level, or maybe sometimes omit the lambda altogether

public void Attach(event CustomEventHandler? evt)
{
    evt += OnCustomEventInternal;
}

all while retaining the benefits of the current event restrictions to maintain control compared to raw delegates.

[timcassell]

It doesn't make sense. How can you pass an event? That's like trying to pass a property. Under the hood, they are just mapped to methods add_EventName, remove_EventName.

C# never should have implemented event in the first place, and rather left them as library implementations (the lang designers themselves have stated as much), so any proposals to expand on them are unlikely to go anywhere. If you want to pass events as parameters, you should use an actual custom event class, not C#'s events.

[LWChris]

You are making it part of the public surface area of your code. And so, the questions around how things are passed around becomes very relevant :)

If the question "how" is about the written syntax, then the answer is in the original proposal:

// Usage: 
Observable.FromEventPattern<FileSystemEventHandler, FileSystemEventArgs>(fsw.Created);

If the question "how" is about how it can be technically done in objects, references, method calls, and IL code, then my answer is "the same way the event keyword is done."

When I write event X that creates a member that can only be used with += and -= and the RHS of those operators is rooted to the right place somehow. And that's the same behavior I'd expect to happen for event parameters. How event works? I don't know. What is necessary under the hood to make event parameters work? I don't know, either. I would know as much about what IL code is actually being generated as I would know for other keyword mechanisms like event, async/await, try/catch/finally, lock, etc. :)

[CyrusNajmabadi]

How event works? I don't know.

With an event you have a receiver and the event itself. so it's not +- in isolation. It is expr.y += .... With expr there is an actual object instance you are operating on. and += is then invoking the add accessor of that event reference specified by y.

In your proposal i don't see how this is accomplished.

[HaloFour]

Events are implemented kind of in a similar manner to properties. The event member itself doesn't really do anything but describe the name and the delegate type of the event, while pointing to the accessor methods used to add/remove handlers to the event. The C# language fakes the += and -= operators, they just boil down to method invocations to add_CustomHandler and remove_CustomerHandler accessor methods. There's no value or anything of the like that can be passed around that represents the event really. That's where some kind of facade would be necessary that encapsulates the two accessor methods.

[HaloFour]

If something like this were to be implemented my vote would be that instead of a special event parameter type or the like that the C# compiler offers syntax candy to transform an event member into a type that wraps the event accessors:

// BCL offers something akin to this:
public struct EventRef<T> where T : System.Delegate {
    object? Target { get; }
    string Name { get; }
    void AddHandler(T handler);
    void RemoveHandler(T handler);
}

// you write this:
var eventRef = obj.CustomEvent;

// lowers into this:
EventRef<EventHandler> eventRef = new EventRef<EventHandler>(
    target: obj,
    name: "CustomEvent",
    addHandler: handler => obj.CustomEvent += handler,
    removeHandler: handler => obj.CustomEvent -= handler
);

Then when you want to have a method that accepts an "event" as a value, you can declare it like this:

public void Attach(EventRef<CustomEventHandler>? evt) { ... }

And call it like this:

Attach(obj.CustomEvent);

// lowers to
EventRef<EventHandler> $temp = new EventRef<EventHandler>(
    target: obj,
    name: "CustomEvent",
    addHandler: handler => obj.CustomEvent += handler,
    removeHandler: handler => obj.CustomEvent -= handler
);
Attach($temp);

Compiler could also add syntax candy to support += and -= operators against the EventRef<T> type.

Names and API shapes are just spaghetti at the wall.

[LWChris]

@HaloFour I like that. If the compiler adds syntax candy to support += and -=, then the only difference between what I envisioned and your code is that I suggested public void Attach(EventRef<CustomEventHandler>? evt) { ... } to be written as public void Attach(event CustomEventHandler? evt) { ... }. But sure, if the class EventRef is framework-provided, there exists a syntax to create by writing obj.CustomEvent, and it supports += and -=, that's all I want and need.

[ds5678]

You could use UnsafeAccessor to get the backing field.

[colejohnson66]

All events have backing fields (m_MyEvent here): https://sharplab.io/#v2:CYLg1APgAgTAjAWAFBQMwAJboNIBsCGAzocgN7LqWYYCmAbjQHYAu6AogywBL6PC40ATgB4OTZgEFBAc0IA+dAFkAnmJYBuZAF8gA===

[HaloFour]

That is not accurate:

https://sharplab.io/#v2:CYLg1APgAgTAjAWAFBQMwAJboNIBsCGAzocgN7LqWYYCmAbjQHYAu6AogywBL6PC40ATgB4OTZgEFBAc0IA+dAFkAnmJbpS6fMGAb0AX3SCaAWwD2DPYf3J9QA==

An event is like a property. Publicly it only has accessor methods. What it has internally is entirely an implementation detail left up to the compiler, and C# does allow you to fully override it.

Even if the event is almost always an "auto-event", there's no guarantee that the fields would be emitted the same way between languages and versions.

[colejohnson66]

That's true, but that's the risk you take with UnsafeAccessor - you're saying "I'm OK with breakage when I upgrade". Same as reflection.

[ufcpp]

add/remove methods of auto-events has mutual exclusion codes, direct access to the backing fileds cannot use that.

[jnm2]

Any approach that assumes a backing field will fail to work in cases like explicit interface implementations. It's uncommon but not that unheard of for an event to be manually implemented, e.g. to delegate to an event somewhere else.

[svick]

This is a duplicate of #2506.

[LWChris]

Yes and no. Making events a first-class citizen has many more implications. But maybe the title is just a misnomer. The use case that inspired the request is exactly the same, the suggested syntax is the exactly the same, the solutions suggested by other people is quite similar.