Proposal: Conditional Assignment Operator (=!) for "assign only if different"

[Aniobodo]

Proposal: Conditional Assignment Operator (=!)
Summary

Introduce a shorthand operator that assigns a value to a variable, field, property, or indexer only if the new value is not equal to the existing one.

obj.A.B.C.D =! newValue;

This expands to:

if (!EqualityComparer<T>.Default.Equals(obj.A.B.C.D, newValue))
    obj.A.B.C.D = newValue;

Motivation

A very common pattern in C# (especially in UI frameworks like WPF, WinForms, MAUI, Blazor, and MVVM code) is:

if (Property != value)
{
    Property = value;
    OnPropertyChanged();
}

Problems with the current approach:

Repetition: the property or path (obj.A.B.C.D) must be written twice.

Error-prone: in long chains it’s easy to accidentally use a different member in the assignment.

Verbose: obscures the intent (“assign if different”) with boilerplate.

Events: extra/unnecessary setter invocations can trigger unwanted notifications.

A dedicated shorthand would reduce noise, clarify intent, and improve correctness.

Detailed Design
Syntax
left =! right;

Semantics

Equivalent to:

if (!EqualityComparer<T>.Default.Equals(left, right))
    left = right;

Uses EqualityComparer.Default for correct semantics across value and reference types.

The left-hand side is evaluated only once (see Desugaring below).

Works with locals, fields, properties, and indexers.

If left is a property returning a value type by copy (no ref return), rules are the same as ordinary assignment — =! cannot be applied.

Desugaring (compiler rewrite)
Example: property chain
obj.A.B.C.D =! newValue;

Becomes:

ref var __temp = ref obj.A.B.C.D;
if (!EqualityComparer<T>.Default.Equals(__temp, newValue))
    __temp = newValue;

Example: indexer
items[i] =! value;

Becomes:

ref var __temp = ref items[i];
if (!EqualityComparer.Default.Equals(__temp, value))
__temp = value;

Notes

Ensures the left-hand side is evaluated once.

Avoids getter side effects being triggered twice.

Mirrors how compound assignments like += are lowered in Roslyn today.

Examples
Cleaner setters

set
{
    _name =! value;
    OnPropertyChanged();
}

Long property chains
// Before

if (customer.Address.City != city)
    customer.Address.City = city;

// After
customer.Address.City =! city;

Indexers
items[i] =! newItem;

Alternatives

Continue using if (x != y) x = y; (status quo).

Use helper methods such as:

SetIfDifferent(() => obj.A.B.C.D, newValue);

(requires expressions, extra allocations/compilation).

Source generators to rewrite property setters.

Drawbacks

Introduces a new operator, increasing language complexity.

Potential learning curve (=! may not be obvious at first glance).

Requires compiler support to ensure single evaluation of left-hand side.

Prior Art

Kotlin’s takeIf / takeUnless (conditional value handling).

Many MVVM frameworks (e.g. Prism, MVVM Light) provide SetProperty(ref field, value) helpers for exactly this purpose.

Community has created numerous SetIfDifferent utilities.

Unresolved Questions

Should a custom comparer (IEqualityComparer) be supported, e.g. via an overload form?

Should the operator be overloadable for user-defined types?

Is =! the best syntax, or would alternatives (:=!, ?=, etc.) be more intuitive?

Conclusion

This proposal reduces boilerplate and errors in one of the most common C# patterns: assigning values only if they differ.

By providing a dedicated =! operator, C# can make intent explicit, improve maintainability, and align with patterns already ubiquitous in property-change scenarios.``

[huoyaoyuan]

A very common pattern in C# (especially in UI frameworks like WPF, WinForms, MAUI, Blazor, and MVVM code) is:

if (Property != value)
{
    Property = value;
    OnPropertyChanged();
}

It doesn't benefit from this. The pattern is used in property setter, not the caller.
In the caller's view, it's just assigning without testing.
In the callee's view, it needs to do more than assignment.

if (!EqualityComparer.Default.Equals(obj.A.B.C.D, newValue))
obj.A.B.C.D = newValue;

This pattern is not commonly used used. The equality test code is usually in C.D setter.
If D is a field instead of property, then the pattern is not useful at all, because field assignment is fully passive.

[Aniobodo]

It’s definitely useful for a property. The pattern of checking before setting is common.

[huoyaoyuan]

It’s definitely useful for a property. The pattern of checking before setting is common.

I don't think it's common. Properties are created for convenience, and should contain necessary checking code instead of leaving it to caller.

[CyrusNajmabadi]

A very common pattern in C# (especially in UI frameworks like WPF, WinForms, MAUI, Blazor, and MVVM code) is:

if (Property != value)
{
   Property = value;
   OnPropertyChanged();
}

I don't see hwo this patten is made better with =!. You won't know if it did the assignment or not, so you won't know if OnPropertyChanged needs to be called or not.

[Aniobodo]

The point here is to avoid triggering the events if the values are equal. Now the check if property == newValue is good enough, but some library authors don’t do that: the newValue is simply reassigned, triggering events.
The consumer, who has no modification access to the property, has to do the check, and the path can be long.

[CyrusNajmabadi]

The point here is to avoid triggering the events if the values are equal. Now the check if property == newValue is good enough, but some library authors don’t do that: the newValue is simply reassigned, triggering events.
The consumer, who has no modification access to the property, has to do the check, and the path can be long.

But the property setter still needs to do the check. Because it doesn't know if the caller is using this pattern. So it saves the caller nothing as both it and the callee will end up doing this.

[koszeggy]

The point here is to avoid triggering the events if the values are equal.

Instead of repeating the same logic in all property setters you can simply derive your observable objects from a base class so you only need to implement the comparison once. This way your properties become:

// Option a.) - If you have a common storage in base
public MyType Property { get => Get<MyType>(); set => Set(value); }

// Option b.) - If you want to use allocate a field for each properties
public MyType Property { get => field; set => Set(ref field, value); }

Where Get/Set methods can have a hidden [CallerMemberName]string propertyName = null parameter.

Option a.) can be useful if many properties may have their default value so they do not allocate memory in the base storage. You might want to choose Option b.) if you have boxing phobia (though every XAML-based frameworks with dependency objects work as option a.), and they perform pretty well).

Many MVVM frameworks (e.g. Prism, MVVM Light) provide SetProperty(ref field, value) helpers for exactly this purpose.

Yes, myself included (see the docs/source for the example option a.) above). But as mentioned above, this way the logic is implemented once, which hardly justifies a brand new operator in the language.

[Aniobodo]

C# 14 comes with the Null-conditional assignment. Some of the arguments in favor of this syntactic sugar apply here.

[CyrusNajmabadi]

set
{
_name =! value;
OnPropertyChanged();
}

This would be undesirable semantics. The setter would always fire. Even if the value didn't change. That breaks this pattern.

[Aniobodo]

set
{
_name = value;
OnPropertyChanged();
}

The above code is the problem, where the caller would want to check the value through the getter before calling the setter. Just setting the property will trigger the event, which could be expensive.

[CyrusNajmabadi]

Just setting the property will trigger the event, which could be expensive.

i don't see how your proposal helps. Most callers will not be checking the property value. They will just set the property. So the setter must check for change. In which case, there's no point in teh caller checking.

[Aniobodo]

I have seen many cases in libraries out of my control where the setter doesn’t do the check.

[jnm2]

Let's use feedback to fix the shortsighted library authoring issue instead of enshrining the shortsightedness with a language feature.

[tannergooding]

This would be a breaking change because =! Is already valid syntax for some types/scenarios, such as bool, due to C# not being a whitespace sensitive language

public void M(ref bool x, bool y)
{
    x =! y;
}

https://sharplab.io/#v2:CYLg1APgAgTAjAWAFBQMwAJboMLoN7LpGYZQAs6AsgBQBOApgGboBGA9mwDboAeANKw7cAngEp8hYlJ7oAvAEJ0wgNySiAX2TqgA

[Aniobodo]

Good observation, any other operator could serve.

[martin-steinhoefer]

Hi,
as I read the first few lines, I thought your proposal aims at Interlocked.CompareExchange, but then you mentioned EqualityComparer and invoking Equals.
I.m.h.o. your proposal mixes different semantic levels. You said, assignment should only take place, if the current value is different from the rhs value, and you want to use an operator for that. To mee the syntax looks like there will be a reference comparison - and assignment, if that returns false (how that would behave on value types without == being overridden, I have no clue). To me the equivalence operators (wich I would assume) are not for value equivalence, as you proposed.

BTW: Value Equivalence like you proposed ist not necessarily symmetric. That has to be ensured by the developer. An asymmetric equivalence implementation would lead to unexpected assignment behavior I guess.

[Aniobodo]

The assignment should not take place if the current value (on the left) is the same (based on default/defined equality) as the rhs.
For value type, the equality should be as implemented. If equality is not implemented for struct, then the operator does not apply (just like == where error CS0019 shows).

[martin-steinhoefer]

Oh sorry, I made a type - corrected the post

[martin-steinhoefer]

However, I personally would infer from the proposed syntax, that reference equality will be checked. That is because of the operator like syntax. Overriding == for value equivalence for reference types is not recommended.

Value equivalence is by far more complex and can have interesting outcomes - especially, if one doesn't expect it to be in place (look out for Equals invocations). With your proposal, one would also have to scan for those =! operators (or any other as that combination is already used).