C# 14 Null-Conditional Assignment: ?. on the Left Side

The null-conditional operator (lesson 051) has always been able to answer "what's in there, if anything." C# 14 finally lets it also answer "put this in there, if there's anywhere to put it."

Lesson 051 taught you ?. as the null-safe way to read a member: var city = customer?.Address?.City; quietly evaluates to null the instant any link in that chain is null, instead of throwing a NullReferenceException. It's one of the most useful pieces of syntax in the language — but only ever on the read side. Try to use it on the write side, as an assignment target, and before C# 14 that was a flat compile error: customer?.Address = newAddress; simply wasn't legal C#. You had to fall back to the exact defensive if block the operator exists to eliminate everywhere else.

In this lesson, you'll learn that C# 14 lifts that restriction: ?. can now appear on the left side of an assignment, meaning "assign this — but only if the thing on the left isn't null; otherwise, skip the assignment entirely and do nothing."

What Is It?

The Simple Explanation

Null-conditional assignment lets you write customer?.Address = newAddress; directly. If customer is not null, the assignment happens exactly as you'd expect. If customer is null, the entire right-hand side is never evaluated, no assignment happens, and — critically — nothing throws. Execution simply moves on to the next statement.

The Technical Definition

C# 14 extends the null-conditional operator (?. and, correspondingly, ?[...] for indexers) to be legal as the target of a simple assignment expression. When the receiver evaluates to null, the entire assignment expression short-circuits: the right-hand side is never evaluated at all — an important detail if that expression has side effects — and the statement completes with no exception and no assignment performed. When the receiver is non-null, the assignment proceeds exactly as an ordinary, unconditional assignment would.

Why Does It Exist?

The Problem — An Asymmetric Operator

The null-conditional operator's whole reason for existing, since lesson 051, has been to collapse "check for null, then act" into one expression — for reads. But the exact same pattern on a write was left completely unaddressed: a conditional assignment still required the full, explicit defensive-if boilerplate the operator was invented to eliminate everywhere else. Developers routinely reached for ?. out of habit when writing to a possibly-null reference, hit a compile error, and had to unwind back to the older, more verbose pattern — an inconsistency that stood out precisely because the operator worked so well everywhere else.

The Solution — Make the Operator Symmetric

C# 14 closes the gap by allowing the exact same ?. syntax to appear on the left of an assignment, with the exact same "null means skip, don't throw" semantics you already know from reads. Nothing new needs to be learned conceptually — it's the same operator, doing the same kind of short-circuiting, in the one remaining place it hadn't been allowed to.

Big Picture

How It Works

Simple Example

Code → Meaning → Result: Both blocks behave identically at runtime. The C# 14 version simply says the same thing in one expression instead of three lines, and — notably — skips constructing the right-hand side entirely when customer is null, since that expression is never reached.

Real-World Example

Consider an event handler pattern you've likely written many times: an optional callback field that a caller may or may not have set. OnStatusChanged?.Invoke(newStatus); is the classic null-conditional read-side pattern for safely raising an event that might have no subscribers. Null-conditional assignment now gives you the same safety on the configuration side: a UI component with an optional, injectable logger — _diagnostics?.LastError = ex.Message; — records the error only if a diagnostics object was actually supplied, without a wrapping if block cluttering what is, conceptually, a single, simple "record this if there's somewhere to record it" operation. Multiply that pattern across dozens of optional dependencies in a large application, and the reduction in defensive-null-check boilerplate adds up.

Analogy

Under the Hood

• Short-circuits before the right-hand side. The compiler generates code that checks the receiver for null before evaluating the value being assigned — if the receiver is null, the right-hand side expression is skipped entirely, not merely its assignment. This matters whenever the right-hand side has observable side effects, such as a method call or a constructor with logging inside it.
• Works for simple assignment only. The feature covers ordinary = assignment through a null-conditional target; it doesn't change anything about compound assignment operators or about the read-side behavior you already knew from lesson 051.
• Same underlying null check either way. Under the hood, this compiles to essentially the same conditional check a hand-written if would produce — there's no meaningful runtime cost difference from the defensive pattern it replaces, just less code to read and maintain.

Common Confusion

1. "The right-hand side always runs, only the assignment is skipped" — no, the whole thing is skipped

It's tempting to assume the value being assigned is always computed and only the final "store it" step is conditional. That's incorrect: when the receiver is null, C# never evaluates the right-hand side at all. If that expression calls a method with a side effect — logging, incrementing a counter, mutating something else — that side effect simply doesn't happen when the receiver is null. This is exactly consistent with how ?. has always short-circuited on the read side, but it's worth stating explicitly, since an assignment's right side is easy to assume "always runs."

2. "This throws if the receiver is null, just like a plain assignment would" — no, it's specifically designed not to

An ordinary customer.Address = newAddress; throws a NullReferenceException the instant customer is null. The entire point of null-conditional assignment is the opposite guarantee: a null receiver means the statement quietly does nothing and execution simply continues — no exception at all. If you actually want an exception when the receiver turns out to be null, this is the wrong tool; keep the ordinary, unconditional assignment for that case.

Common Mistakes

Mistake 1 — Using it where a null receiver should actually be an error

Reaching for customer?.Address = newAddress; in a code path where customer being null genuinely represents a bug — silently swallowing what should have been a loud, early failure, and letting the program continue in a state its author never intended.

Use null-conditional assignment specifically where "there's genuinely nothing to do" is a legitimate, expected outcome — an optional dependency, an event with no subscribers. Where a null value is actually invalid, keep an explicit check (or lesson 041's exception-throwing patterns) so the bug surfaces immediately instead of being silently absorbed.

Mistake 2 — Assuming the right-hand side always executes

Writing logger?.LastMessage = ComputeExpensiveDiagnostic(); and assuming ComputeExpensiveDiagnostic() always runs regardless of whether logger is null — then being surprised when a side effect inside it (like a counter increment) doesn't happen in some code paths.

Remember that the right-hand side is skipped entirely when the receiver is null. If a right-hand-side expression's side effects must always happen regardless of the receiver, compute it in a separate statement first, then assign it unconditionally.

When Should I Use It?

• Whenever you'd otherwise write a single-statement if (x != null) x.Member = value; block — this is the exact pattern the feature is meant to collapse.
• For genuinely optional targets — an injected dependency that might not be configured, an object that legitimately may or may not exist in this code path.
• Not where a null receiver represents an actual bug that should be surfaced loudly — keep explicit validation and exceptions there instead.
• Be mindful when the right-hand side has side effects you need to guarantee happen — compute it separately first if so.

Mental Model

Key Takeaway

Check Your Understanding

Let's confirm the short-circuiting behavior — including the right-hand-side subtlety — landed clearly.

The null-conditional operator you learned in lesson 051 is now fully symmetric — safe on reads and safe on writes. Lesson 327 continues the Part XII tour with enhanced span conversions, and more C# 14 additions follow right after.