Proposal: Registering to events if handler is not already registered

[Ultrahead]

When you register a handler to an event, the CLR does not check whether it is already registered and therefore, registration happens again.

A common practice to avoid this, is to unregister the hander first and then register it (which could bring race threats). Alternative ways can be implemented by getting the invocation list of the event (directly or through reflection).

The idea is to simplify things by allowing a sentence like, say:

myObject.MyEvent? += MyEventHandler;

This will let the CLR know that MyEventHandler must be register to the event only if NOT already registered.

Additionally, a special check could be added to the language, like:

if(myObject.MyEvent != MyEventHandler)
{
  myObject.MyEvent += MyEventHandler; 
}

The latter would spare us from writing code to check the invocation list of the event. And both features, will avoid the unregistering step.

Thoughts?

[HaloFour]

This wouldn't be possible for the C# compiler (or the CLR for that matter). The event only exposes two methods, add and remove. The += and -= syntax is just candy for invoking one of those two methods. What those methods do internally is entirely a blackbox. So there's nothing that the compiler can really do to try to prevent duplicate subscription from the subscribers point of view.

It's possible that the C# compiler could emit different code in the add method to deal with duplicates when defining an event, but that doesn't help for subscribing to events on different classes.

[Ultrahead]

In order to accomplish the syntax sugar I'm proposing the methods exposed by the event should be extended, to something like: add(boolean) or addIfNotPresent, and contains.

[svick]

You can do this on the side of the event by having custom add and remove accessors. For example:

private HashSet<EventHandler> e = new HashSet<EventHandler>();

public event EventHandler E
{
    add => e.Add(value);
    remove => e.Remove(value);
}

private void RaiseE()
{
    foreach (var handler in e)
        handler(this, EventArgs.Empty);
}

[Ultrahead]

Yes, I know. But what about the events that you consume but not declare? You end up either unregistering the handler first or use reflection to get the invocation list which ends up being unintuitive, cumbersome, risky and not performance-wise.

[HaloFour]

@Ultrahead

Changing the signature of the method used to add the handler couldn't be done from the subscriber side anyway. And I'm pretty sure that would be a massive breaking change, even if the CLR would allow such a signature to be used in the .add slot of the event.

[Ultrahead]

Don't change the signature (if you do not want to use an optional parameter at the end), and implement a new one, as I said before as an alternative: "addIfNotPresent". This one would be used by: myObject.MyEvent? += MyEventHandler;

And "contains" by if(myObject.MyEvent == MyEventHandler) or if(myObject.MyEvent != MyEventHandler).

[jnm2]

This would require a new CLR and System.Reflection and then it would require all existing assemblies to be recompiled to declare these new accessor methods. Even then, I've read that failing to track subscription state yourself is a code smell and I'm pretty sure that's correct. I'd rather this "just in case unsubscribe" pattern was a bit in-your-face to discourage its use.

[Ultrahead]

I understand, but the problem with this "pattern" is that it opens the door for issues, like race conditions and perf penalties. And now that many perf issues have been addressed (and solved) from C# v7.x and on, it may be time to address those code smells regarding events from within the kernel it-self.

[jnm2]

I'm not sure which pattern you're referring to. The "just in case unsubscribe" pattern? It sure does have problems, not least of which is that it fundamentally causes memory leaks.

[Ultrahead]

Never said it causes memory leaks.

[jnm2]

No, I brought that up because memory leaks are one of the things that motivated me to get away from the -=, += pattern and see it as an antipattern.

[yaakov-h]

-=, += tells me that the application has no idea if it's subscribed or not, but wants to be.

I agree with the code smell - we should be better managing object lifecycle and subscriptions, rather than doing a conditional subscribe or clear-and-subscribe.

[bondsbw]

This thread describes why I left += and -=. I wouldn't mind if a really good, first-class replacement were introduced.

[Ultrahead]

Is this proposal is being somehow considered?

[CyrusNajmabadi]

@Ultrahead When things change, the issue will be updated. There is no need to go through all your issues asking for status updates. Thanks :)

[Ultrahead]

Well, there is for me. I'm cleaning my plate and closing discarded issues.

[CyrusNajmabadi]

@Ultrahead Issues have not been discarded. They simply haven't been triaged or assigned a specific release.

[jnm2]

@Ultrahead Just so you know, everyone that follows the repo got some repetitive notifications when you did this.

[Ultrahead]

Sorry about that, but there should a policy in place to either triage proposals in specific period of time or close them. It's been more than two years since I opened the issue and also with neither movement nor signal of interest from champions so imvho this should be closed ufn. Please respect my will as author of the proposal and do not reopen it unless the intention is to provide a meaningful discussion towards its implementation. Thanks

[CyrusNajmabadi]

Reopening issue so it can go through the normal design process.

[CyrusNajmabadi]

Sorry about that, but there should a policy in place to either triage proposals in specific period of time or close them.

Sorry. We don't have such a policy. Design work is not based on time but on how important things are as judged by the ldm.

It's been more than two years since I opened the issue and also with neither movement nor signal of interest from champions

There are issues that go for decades without movement, up until the point they become important enough for the next release :-)

so imvho this should be closed ufn.

I don't see any reason to close this. It's an interesting space, and maybe there's stuff the language can do (i.e. around managing lifetimes) to make things better.