What's New in C# 14: Null-Conditional Assignments

> I don't think it is normal to follow the flow assuming nothing has happened.

I think it is for situations where the programmer wants to check a child property but the parent object may be null. If the parent is expected to be null sometimes, the syntax lets the programmer express "try to get this value, but if we can't then move on" without the boilerplate of explicitly checking null (which may be a better pattern in some cases).

It's sort of like saying:

- Get the value if you can, else move on. We know it might not be there and it's not a big deal.

v.s.

- The value may not be there, explicitly check and handle it because it should not be null.

From the article:

> If config?.Settings is null, the assignment is skipped.

If the right hand expression has side effects, are they run? I guess they do, and that would make the code more predictable.

  (vector-set/drop v -2 (print "banana"))

It’s for the use case where they’d skip it anyway so that would be intended behavior.

It kind of is more confusing because I always imagined the RHS to be evaluated first in an assignment, before the target is evaluated.

The motivation is that you don't want the side effects in some cases like GetNextId() but I think it's still strange. I hacven't thought deeply about it but i _think_ I'd rather keep the intuitive right-hand-first evaluation and explicitly have to use if (..) in case I have a RHS whose side effects I need to avoid when discarded.

That's already the case for the null coalescing operator when it ends in a method call: the method call is skipped if the base is null. For instance, we can invoke event handlers with "myEvent?.Invoke(...);" and the call will be skipped if there are no event handlers registered, and this is the canonical way to do it.

You can use newer LangVersion in framework too.

This is explicit though. The question mark operator is the developer explicitly asking for this behavior.

A representative config.connection being made out of nothing sounds pretty bad to me. If you want to make sure the value doesn't disappear, you shouldn't be using conditional assignment in the first place.

The config example isn't the best, but instead imagine if it was just connection.?retryPolicy. After you set connection?.retryPolicy it would be weird for reading it back to be null. But it would be just as weird for connection?.retryPolicy to not be null when we never established a connection in the first place.

The copy on write analogy is tempting but what you're describing only works when the default value is entirely made of nulls. If you need anything that isn't null, you need to actually make an object (either upfront or on first access). And if you do that, you don't need ?. anymore.

> When you have an expression P which names a mutable place, and you execute P := X

This isn't the case, though, is it? A normal member access (or indexer) expression may point to a mutable location (field, property). However, with conditional access expressions you get either a member access _or nothing_. And that nothing is not a mutable place.

When you use any of the conditional operators, you split the following code into two paths, and dropping the assignment (since there's nothing to assign to) seems pretty consistent to me, since you'd also drop an invocation, or a property evaluation in similar expressions.

If you require P to point to something that actually exists because you want the assignment to succeed, then write code to ensure that P exists because the assignment has no way of knowing what the intention was on the left side.

This is syntactic sugar only. No change in semantics. So I don't buy into any argument about what this change 'means'.

And we all get to choose what we find ridiculous:

i = i + 1 ? No it does not. Never has, never will.

Connection is null? It's insane to type it as Connection then. null has type Null.

  a.b?.c = foo

  a.b?.c = foo

  a.b?.c = foo

  Main.cs(19,9): error CS0131: The left-hand side of an assignment must be a variable, property or indexer

  using System;

  public class A
  {
    public B b { get; set; }
  }

  public class B
  {
    public int? c { get; set; }
  }

  public class Program. 
  {
    public static void Main()
    {
      A a = new A { };
      int foo = 42;
      a.b?.c = foo;
    }
  }

Apparently you do t use if in your code?

What?.could?.possibly?.go?.wrong?.

    if (This) {
        if (is) {
            if (much) {
                if (better) {
                    println("I get paid by the brace")
                }
            }
        }
    }

  if (!same) {
    return;
  }

  if (!number) {
    return;
  }

  if (!of_braces) {
    return;
  }

  println("but easier to read")

  what?.could?.possibly.go?.wrong = important_value()

  if (!what)
    what = new typeof(what); // default-construct representative instance

  if (!what.could)
    what.could = new typeof(what.could);


  if (!what.could.possibly.go)
    what.could.possibly.go = new typeof(what.could.posssibly.go)


  // now assignment can take place and actually retain the stored value
  // since we may have allocated what, we have to be sure
  // we propagate it out of here.

  what.could.possibly.go.wrong = important_value();

  foo f = { .a = x(), .a = y() }

    if (Actually 
        && Actually.you
        && Actually.you.would
        && Actually.you.would.write
        && Actually.you.would.write.it
        && Actually.you.would.write.it.like) {
            return this;
    }

  What?.could?.possibly?.go?.wrong?

  What?.could?.possibly?.go?.wrong = important_value()

And more better? I'm not sure either.

In all these examples I feel something must be very wrong with the data model if you're conditionally assigning 3 levels down.

At least the previous syntax the annoyingness to write it might prompt you to fix it, and it's clear when you're reading it that something ain't right. Now there's a cute syntax to cover it up and pretend everything is okay.

If you start seeing question marks all over the codebase most of us are going to stop transpiling them in our head and start subconsciously filtering them out and miss a lot of stupid mistakes too.

Hi there! Lang designer here.

> More concise? Yes.

Note: being more concise is not really the goal of the `?` features. The goal is actually to be more correct and clear. A core problem these features help avoid is the unfortunate situation people need to be in with null checks where they either do:

    if (some_expr != null)
        someExpr...

Or, the more correct, but much more unweildy:

    var temp = some_expr;
    if (temp != null)
        temp...

`?` allows the collapsing of all the concepts together. The computation is only performed once, and the check and subsequent operation on it only happens when it is non-null.

Note that this is not a speculative concern. Codebases have shipped with real bugs because people opted for the former form versus the latter.

Our goal is to make it so that the most correct form should feel the nicest to write and maintain. Some languages opt for making the user continuously write out verbose patterns over and over again to do this, but we actually view that as a negative (you are welcome to disagree of course). We think forcing users into unweildy patterns everywhere ends up increasing the noise of the program and decreasing the signal. Having common patterns fade away, and now be more correct (and often more performant) is what we as primary purposes of the language in the first place.

Thanks!

Swift has had this from the beginning, and it doesn’t seem to have been a problem.

Oh come on just learn it properly it's not a big deal to read it

When the first wave of null check operators came out our code bases filled up with ? operators. I luckily had used the operator in swift and rust to somewhat know what it can do and what not. Worse the fact that unlike rust the ? operator only works on null. So people started to use null as an optional value. And I think that is at the core the problem of the feature. C# is not advertising or using this themselves in this way. I think the nullable checks etc are great way to keep NPE under control. But they can promote lazy programming as well. In code reviews more often than not the question comes up, when somebody is using ? either as operator or as nullable type like ‘string?’, are you sure the value should be nullable? And why are you hiding a bug with a conditional access when the value should never be null in the first place.

That's what's new in c#14, it allows you to do

    customer?.Profile?.Avatar = "thing" 

And will do nothing if the left hand side is null (not throw a null reference exception anymore)

Yes but they already had it for non-assigning uses.

I'm also not sure I have a lot of code where this would be useful, but adding it to the language I don't feel makes it worse in any way; in fact, it makes it more consistent since you can do conditional null reads and conditional null method invocations (w/ `?.Invoke()`), so why not writes too.

improving crappy codebases without breaking anything. Bad .NET developers are forever doing null checks because they write weird and unreliable code. So if you have to fix up some pile of rotting code, it can help you slowly iterate towards something more sane over time.

For example in my last gig, the original devs didn't understand typing, so they were forever writing typing code at low levels to check types (with marker interfaces) to basically implement classes outside of the classes. Then of course there was lots of setting of mutable state outside of constructors, so basically null was always in play at any moment at any time.

I would have loved this feature while working for them, but alas; they were still on 4.8.1 and refused to allow me to upgrade the codebase to .net core, so it wouldn't have helped anyway.

Monad-maxxing has ruined many a language

Hi there, one of the lang designers here :)

Think of it this way. We already supported these semantics in existing syntax through things like invocations (which are freely allowed to mutate/write). So `x?.SetSomething(e1)`. We want properties to feel and behave similarly to methods (after all, they're just methods under the covers), but these sorts of deviations end up making that not the case.

In this situation, we felt like we were actually reducing concept count by removing yet another way that properties don't compose as well with other language features as something like invocation calls do.

Note: when we make these features we do do an examination of the ecosystem and we can see how useful the feature would be. We also are community continuously with our community and seeing just how desirable such a feature is. This goes beyond just those who participate on the open source design site. But also tons of private partners, as well as tens of thousands of developers participating at our conferences and other events.

This feature had been a continued thorn for many, and we received continuous feedback in the decade since `?.` was introduced about this. We are very cautious on adding features. But in this case, given the continued feedback, positive reception from huge swaths of the ecosystem, minimal costs, lowered complexity, and increased consistency in the language, this felt like a very reasonable change to make.

Thanks!

The difference is the language syntax choices are good. There's no "what does this const refer to" type confusion.

There's a couple reasons I disagree with you on this (at the moment; as given enough time I am sure C# will also jump the shark):

* The above is just applying an existing (useful) feature to a different context. So there isn't really much learning needed, it now just 'works as expected' for assignments and I'd expect most C# engineers to start using this from the get go.

* As a C# and C++ developer, I am always excited to hear about new things coming in C++ that purportedly fix some old pain points. But in the last decade I'd say the vast majority of those have been implemented in awful ways that actually make the problem worse (e.g. modules, filesystem, ...). C#'s new features always seem pretty sound to me on the other hand.

This is syntax sugar. Don’t conflate syntactic niceties with the semantic absurdity that C++ has.

That's why I keep using Golang instead of C#, even though C# is better in a lot of ways. But with Go, I normally can understand any sourcecode I'm control clicking into.

I've never gotten to this point with any other language, no matter how hard I tried.

A C# dev can't complain, because complexity creates job.

At a social level, I 100% agree with you because I’ve started to see those behaviours in the community. But considered technically, C++ is on a whole different level from C#. The community seems to embrace “What does this print?” style puzzles, and figuring out when perfect forwarding or SFINAE kick in is genuinely tricky.

Static abstract methods are probably the feature I see used least (so far!) and they’re not nearly as hard to understand as half of the stuff in a recent C++ standard.

I've been using .Net for almost 20 years, professionally for half that time, and I feel like excitement and momentum in the community has only been increasing.

I personally can't think of an all-rounder language that is better than C#. It's fast, has great tooling, powerful, extremely productive for working with large code bases and runs 'anywhere'.

JS has lost against TS which is basically C# for web (both designed by the same person) and Python is not really something you should build large applications with (execution speed + maintenance issues).

What do you believe is the current language du jour?

I'd say it's never been better tbh. I can't speak for Gen Z but .NET (for some reason) was never the choice of startups. Possibly because there is still a cost associated with the best developer experiences, such as for the best IDE's in editions that allow any size of for-profit org.

Well, JavaScript is older than C# and still poppin. Gen Z eats it up. C# too, for unity gamez.

It is definitely out of fashion, most directly in comparison to Go I suppose. It seems like they tried with .NET Core, but were not able to provide an appealing and coherent enough on-ramp. The ongoing death of native windows applications not helping either certainly.

You’re not wrong. Every language feature that gets added there’s someone who wants to stop the clock and hold the language definition in place because “people might misuse it” or “people might not be familiar with it”. It’s not language specific, it’s everywhere.

Why the requirement, because of J++ and how Ext-VOS alongside Cool became .NET?

Most companies don't care about this kind of stuff.

I work across Java, C#, JS/TS, C++, SQL, and whatever else might be needed, even stuff like Go and C, that I routinely criticise, because there is my opinion, and then there is the job market, and I rather pay my bills.

When you don't, you'd likely have an Maybe<string> for a username that would be a "string?" in C#. It's the same thing (more or less). For your optional type you still need some form of pattern matching to figure out whether you have it or not.

You can't banish the "absence of value" from any programming language. That wouldn't be a useful language. You can stop confusing "a string but perhaps not" as a single type "string" as C# did in the past though.

Nothing is stopping you from constraining the language version you want to be used in your projects:

https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

You can force it all the way down to ISO-1/2.

If this is still insufficient, then I question what your goals actually are. Other people using newer versions of C# on their projects shouldn't be a concern of yours.

Yes, this doesn't actually add anything to the "size" of the language, if anything it actually shrinks it. It's existing syntax (the ? and ?? operators) and existing semantics. The only thing was that it worked in half the cases, only reads but not writes. Now this completes the functionality so it works everywhere.

You can argue that C# gets a lot of new features that are hard to keep up with, but I wouldn't agree this is one of them. This actually _reduces_ the "mental size" of C#.

  Settings?.RetryPolicy = new ExponentialBackoffRetryPolicy();

    Settings?.SetRetryPolicy(new ExponentialBackoffRetryPolicy());

    if (myObj is not null)
       myObj.Id = GetNextAvailableId(); // Side effect

    Settings?.RetryPolicy = new ExponentialBackoffRetryPolicy();

    var id = GetNextAvailableId();
    if (myObj is not null)
       myObj.Id = id;

> Cute, but is this actually needed? It's one more thing to remember, one more thing to know the subtleties of, and for what?

Hi there! C# language designer here :-)

In this case, it's more that this feature made the language more uniform. We've had `?.` for more than 10 years now, and it worked properly for most expressions except assignment.

During that time we got a large amount of feedback from users asking for this, and we commonly ran into it ourselves. At a language and impl level, these were both very easy to add in, so this was a low cost Qol feature that just made things nicer and more consistent.

> It feels like the C# designers have a hard time saying "no" to ideas coming their way.

We say no to more than 99% of requests.

> We're trading brevity for complexity

There's no new keyword here. And this makes usage and processing of `?.` more uniform and consistent. Imo, that is a good thing. You have less complexity that way.

I don't get this argument as it really doesn't match my practical experience. Using new C# features, the code I write is both easier to read and easier to write. On top of that it's less error prone.

C# is also much more flexible than languages you compared it to. In bunch of scenarios where you would need to add a second language to the stack, you could with C# still use just one language, which reduces complexity significantly.

Agreed, it appears that since they changed to early release their have become pressured to add new language features every year.

As polyglot I have the advantage that I don't have to sell myself as XYZ Developer, and increasingly I don't think C# (the language itself) is going into the direction that I would like, for that complexity I rather keep using C++.

Just wait for when extension everything, plus whatever design union types/ADT end up having, and then what, are they going to add on top to justify the team size, and yearly releases?

Despite my opinion on Go's design, I think the .NET team should take a lesson out of them, and focus on improving the AOT story, runtime performance, and leave the language alone, other than when needed to support those points.

Also bring VB, F# and C++/CLI along, this doesn't not have to be C# Language Runtime, where it gets all the features of what designed as a polyglot VM.

I went to the .NET Developer Conference (NDC) in London at the beginning of the year. Mads Torgersen (Lead C# Designer, for anyone not in the know) gave a talk about some new proposed features. After describing a proposal to introduce new syntax to make defining extension methods easier, he asked if anyone had any questions. I asked a question along the lines of:

"I understand we sometimes need to address deficiencies in a language, but when we do stop? More syntax is leading to daily decision fatigue where it's difficult to justify one approach over another. I don't want C# to become C++."

It was interesting listening to the discussion that took over from that. The audience seemed in favour of what I said, and someone else in the audience proposed a rolling cut-off to deprecate older features after X years. It sounded very much like Mads had that discussion internally, but Microsoft weren't in favour. I understand why, but the increasing complexity of the language isn't going to help any of us long-term.

I stumbled over this a few times, mostly when cleaning up older code. This basically just means that using the ?. member access no longer dictates what is possible on the right side.

Property reads were fine before (returning null if a part of the chain was null), method invocations were fine (either returning null or just being a no-op if a part of the chain was null). But assignments were not, despite syntactically every ?. being basically an if statement, preventing the right side from executing if the left side is null (yes, that includes side-effects from nested expressions, like arguments to invocations).

So this is not exactly a new feature, it just removes a gotcha from an old one and ensures we can use ?. in more places where it previously may have been useful, but could not be used legally due to syntax reasons.

> is this actually needed

Yes, actually. I did write it multiple times naturally only to realize it was not supported yet. The pattern is very intuitive.

Life quality upgrade - needed? Depends.

Hi there. C# lang designer here :)

Discriminated unions continue to be worked on, and you can see our latest designs here: https://github.com/dotnet/csharplang/blob/main/proposals/uni...

The space there is large and complex, and we have a large amount of resources devoted to it. There was no way that `a?.b = c` was going to change if/when unions come to the language.

For unions, nothing has actually been delayed. We continue working hard on it, and we'll release it when we think it's suitable and ready for the future of the lang.

The only feature that actually did get delayed was 'dictionary expressions' (one that i'm working). But that will hopefully be in C# 15 to fill out the collection-expression space.

Discriminated unions are a hard feature to put into a mature language that already has other features in a similar space - I mean enums and class hierarchies. (.e.g. if your union is "Cat or Dog", then in OO terms they have a common base class "Animal" ). How does it play with records, structs, generics, etc etc.

That is why although they are much requested, none of the proposals that I have seen are simple to understand or easy to implement, and thus are proceeding slowly.

I don't really see Discriminated union as being in "competition" with "a?.b = c" as that's a "quick win" extension to previous ?. and ?? syntax. It's not even close to being of the same magnitude.

I would settle for a good built-in Result<T, E> type, so that people don't roll their own crappy ones, or use various opinionated but incompatible libraries.

> wants C# to be Python or whatever

Oh, how happy would I be if Python had a sliver of C# features. There's nothing like null-conditionals in Python, and there are many times I miss them

That as much is true, that is why stuff like minimal APIs and now aspire came to be, they want to cater to the JavaScript and Python folks, they have said as much in a couple of .NET podcast interviews.

Additinoally, I think they are becoming hostage that every year C# gets a new release, thus the team has to keep pushing features no matter what.

Imagine how C# will look a decade from now with this rythm.

Slowly I am starting to think it is not that bad, that most of the .NET projects that our agency does are still stuck on Framework.

I have long desired such a language feature. It is a great addition to the language, because a single such expression helps to avoid potential bugs caused by mismatching double references in the conditional test and the execution statement of the traditional version, especially when refactoring longer code blocks.

For example, if we have something like this:

    if (config?.Settings is not null) 
    {
        ... Multiple lines that modify other settings.
        config.Settings.RetryPolicy = new ExponentialBackoffRetryPolicy();
    }

and we introduce another category SpecialSettings, we need to split one code block into two and manually place each line in the correct code block:

    if (config?.Settings is not null) 
    {
        ... Multiple lines that modify other (normal) settings.
    }
    if (config?.SpecialSettings is not null) 
    {
        ... Multiple lines that modify other special settings.
        config.SpecialSettings.RetryPolicy = new ExponentialBackoffRetryPolicy();
    }

With the new language feature the modification is easy and concise:

    config.Settings?.RetryPolicy = new ExponentialBackoffRetryPolicy();

becomes:

    config.SpecialSettings?.RetryPolicy = new ExponentialBackoffRetryPolicy();

and can be made for any other special setting in place, without the need to group them.

Furthermore, I find the "Don't Overuse It" section of the article somewhat misleading. All the issues mentioned with regard to

    customer?.Orders?.FirstOrDefault()?.OrderNumber = GenerateNewOrderNumber();

would apply to the traditional version as well:

    if (customer is not null)
    {
        if (customer.Orders is not null)
        {
            if (customer.Orders.FirstOrDefault() is not null)
            {
                customer.Orders.FirstOrDefault().OrderNumber = GenerateNewOrderNumber();     
            }        
        }
    }

or:

    if (customer is not null)
    {
        var orders = customer.Orders;
        if (orders is not null)
        {
            var firstOrder = customer.Orders.FirstOrDefault();
            if (firstOrder is not null)
            {
                firstOrder.OrderNumber = GenerateNewOrderNumber();     
            }        
        }
    }

If it really were a bug, when customer is null here, etc., then it would of course make sense to guard the code as detailed as described in the article. However, this is not a specific issue of the new language feature. Or to put it more bluntly:

   customer?.Orders?.FirstOrDefault()?.OrderNumber = GenerateNewOrderNumber();

is no replacement for

   customer.Orders.First().OrderNumber = GenerateNewOrderNumber();

were we want an exception on null.

BTW, with the new version, we can also make the code even clearer by placing each element on its own line:

    customer?
    .Orders?
    .FirstOrDefault()?
    .OrderNumber = 
        GenerateNewOrderNumber();

You must not do a lot of C# code reviews? This syntax is used in every codebase. In fact if you don't use it Visual Studio will underline it as "code can be simplified" suggestion.

You've never seen something like this?

    MyEvent?.Invoke(sender, arg);

I have occasionally, just for fun, written benchmarks for some algorithm in C++ and an equivalent C# implementation, them tried to bring the managed performance in line with native using the methods you mention and others. I'm always surprised by how often I can match the performance of the unmanaged code (even when I'm trying to optimize my C++ to the limit) while still ending up with readable and maintainable C#.

That is the promise we could already have had in the 1990's with languages like Eiffel, Oberon and Modula-3, and it has taken us about 30 years to finally become mainstream.

C# is not the only one offering these kind of capabilities, still big kudos to the team, and the .NET performance improvements blog posts are a pleasure to read.

That would look strange IMHO. Why wouldn't it be a.["b"] then?