Proposal: Add +== and *= operators for idempotent and weak event subscriptions in C#

[rudolfstepan]

Event Operator Proposal for C#

This proposal introduces two new C# operators for event handling, aimed at improving safety, expressiveness, and developer ergonomics in event-driven code:

• +== — Idempotent event registration
  Adds an event handler only if it hasn't already been registered.

• *= — Weak event registration
  Registers a handler without creating a strong reference, helping to prevent memory leaks in publisher/subscriber patterns.

---

✨ Motivation

C# has made great strides in improving language clarity and reducing boilerplate with operators like ??, ??=, and ?... However, event handling remains relatively low-level and prone to common runtime pitfalls:

• Duplicate event registration often leads to handlers firing multiple times.
• Memory leaks can occur when events hold strong references to long-lived subscribers.

These proposed operators address those issues directly, while maintaining the elegance and intent-revealing nature of C#.

---

💡 Examples

button.Clicked +== OnClick; // Only adds OnClick once, even if called multiple times

timer.Tick *= WeakHandler; // Adds handler weakly; GC can collect the target if not used elsewhere

These operators would significantly simplify codebases relying on dynamic subscriptions or MVVM/Reactive architectures.

---

📎 Full Proposal

The detailed rationale, design considerations, examples, and potential syntax alternatives are outlined here:
👉 https://github.com/rudolfstepan/event_operator_proposal

---

🔧 Implementation considerations

These operators could be:

• Implemented as syntactic sugar over existing event add/remove accessors
• Supported via compiler-generated logic that checks for duplicates or uses WeakReference
• Treated similarly to how the C# compiler already handles lambda closures and expression trees

---

🧩 Compatibility

• Fully backward-compatible
• No breaking changes to existing syntax
• Avoids overload ambiguity by using previously unused operator combinations

---

A working example using legacy C#:

I’ve implemented the core idea of a weak event handler pattern in a production-ready form here:

https://github.com/rudolfstepan/event-driven-framework/blob/master/src/EventDriven.Core/EventBus/WeakEventBase.cs

---

🙏 Closing

This proposal aims to bring modern expressiveness and safety to one of C#'s most fundamental patterns.
Feedback and further discussion are very welcome!

[huoyaoyuan]

Idempotent is coupled with implementation of event, not its API surface.

It's not possible to use different operators by the callers to implement these. The += operator is just a plain method call of add_EventName(delegate). For Idempotent, the caller can't know what's already registered in the event. It can't do anything for idempotent.

---

For weakness, it is possible for the caller to construct a indirect weak closure, but the transformation is too much. It's also not so inefficient.
Using custom operator is also not readable. It should be a library feature rather than a language feature.

[rudolfstepan]

Thank you for your feedback – much appreciated.

You're right that idempotency and weak references are ultimately matters of implementation. However, the goal of operators like +== or *= is to make intent clearer at the call site, and to encourage safe and consistent patterns in event handling.

Developers today often implement idempotent registration manually using GetInvocationList() or similar workarounds – which is both verbose and error-prone. A dedicated operator would not change what's possible, but it would improve clarity, readability, and safety, just like ??=, with, or => did in their respective domains.

Regarding weak events: my framework provides a working, production-ready example using standard C#: WeakEventBase.cs
It shows that the concept is feasible, but also why language-level support would reduce boilerplate and cognitive overhead.

Ultimately, the goal is not to introduce magic, but to better express what developers already try to achieve – and to make the safe, clear path the easiest one to follow.

I've been working with C# since its early days, and over the decades, I've seen many things evolve beautifully – from delegates to LINQ, from generics to async/await.
But I've also noticed which patterns still require workarounds, verbosity, or defensive coding – especially in event handling.
+== and *= are not about changing the fundamentals, but about completing the expressiveness of the language in a way that matches how we write and think today.

[huoyaoyuan]

Operators are very, very unreadable without wide agreement about semantic. ?? is a simple if-else with a simple null test. => is a syntax structure like braces. Variants of event operations isn't self-descriptive.

Currently auto events are implemented with calling Delegate.Combine and Delegate.Remove. Any idempotent registration support should at first be a library feature before getting any language support, if ever.

[colejohnson66]

IMO (and also that of some on the dotnet team) is that events themselves shouldn't have been a first class feature in C# at all — they should've been a library feature. Multicast delegates themselves are already very frustrating when it comes to optimizations and DX. Adding more complexity into events is just asking for trouble.

[HaloFour]

Idempotency isn't something that could be managed by the consumer of the event as they have no insight into how the event is implemented internally or whether or not that delegate target is already in an invocation list (if there is one). It'd be up to the publisher to implement the check within the event registration.

As for weak registration, that could be handled on the consumer side by wrapping the delegate in an implementation that keeps a weak reference to the target. However, that comes with it's own set of issues as wrapping the target delegate with a different implementation would break any idempotency checks above. I also don't think that this is nearly common enough to warrant a language feature and it is already solvable through libraries.

[rudolfstepan]

Recent comments correctly point out that advanced event-model features (idempotent registration, weak handlers, custom operators) are better served by a standalone library rather than baked into the language itself. This avoids adding new, potentially confusing syntax to C# and keeps the core language simpler.

👉 Idempotent registration and weak-reference handlers can be implemented today without any new operators—just a small helper library.
👉 New operator proposals (e.g. ?=, specialized event braces) risk poor discoverability and uneven adoption.

Already Available: Weak Event Framework
To demonstrate exactly this approach, I’ve published Weak Event Framework:
🔗 https://github.com/rudolfstepan/weak-event-framework

Idempotent “+=”/“–=”, no duplicate handlers

Automatic cleanup of dead (garbage-collected) subscribers

Thread-safe, lock-based design with copy-on-write semantics

No language changes required—just install the NuGet package and import WeakEventBus.Core

Feel free to try it out or review the source; it shows how all the desired capabilities can live in a library, keeping the language spec lean and focused.