Proposal: Implement -+= in events

[banjouuid]

Currently when we have an event is very common to unsubscribe before and then subscribe to it again:

_service.FileDownloaded -= FileDownloaded; _service.FileDownloaded+= FileDownloaded;

this could be easily put in a more concise way like:

_service.FileDownloaded -+= FileDownloaded;

First unsubscribe and then subscribe again. This will reduce a lot the number of lines in loads of projects with a moderate amount of events.

[tannergooding]

@nanddobanjo, why do you need to unsubscribe and immediately resubscribe?

[banjouuid]

To make sure you don't subscribe Twice, sometimes the code might be called 2 times or 3 times and you want it to only to hold one subscription.

[tannergooding]

I feel like that is the purpose of custom add and remove methods (when implementing your own events).

If you are consuming someone else's method, then having a wrapper method that calls -= and then += is trivial enough to implement.

That being said, I'm not sure how widespread code like the above is, so I couldn't say how much impact a feature like this would have 😄

My other thought is that there are much better ways to do this that don't require you to unsubscribe. In general, when you unsubscribe and then resubscribe, there is a brief window in which you can miss an event that you would have otherwise gotten (assuming that the unsubscribe actually removes an existing handler). So tracking whether or not you have already subscribed externally is likely preferable.

[sharwell]

I currently lean 👎 here. It seems like the desired behavior is a NOP if the event is already registered. However, what appear to be the obvious implementations of this feature have two downsides in practice:

1. If the delegate is already added, the list gets reordered so the delegate moves to the end.
2. If the delegate is already added, there is a window where it's possible for an event to get dropped by the listener. Users are likely to expect that once registered, all events are observed until unregistered (with -=).

If these downsides are not resolved, then even if the feature gets added users will be discouraged from using it. I find it hard to advocate for a feature knowing I would later discourage its adoption.

[jnm2]

Agree with @sharwell's points. The need to unsubscribe and resubscribe means that you're working with a very poor design that doesn't take proper responsibility for cleanup. Whether that's your fault or a third party's fault, the language shouldn't make the poor design look better than it is.

[ygc369]

@jnm2 @sharwell @tannergooding
Is there any way to check whether it is already subscribed?

[HaloFour]

@ygc369

Is there any way to check whether it is already subscribed?

Not externally. Events are just syntax candy to two methods, one for adding a subscriber and one for removing a subscriber. There's no way for a subscriber to get a list of existing subscribers, or to determine whether or not a delegate is already subscribed.

[tannergooding]

If it is an event of your class, you can get the subscribers as with an other delegate.

[jnm2]

@ygc369 You don't, whoever subscribes is responsible to track and unsubscribe.