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

The thing I enjoy most about C# is the depth/levels of progressive enhancement you can do.

Let's say in the first instance, you write a proof of concept algorithm using basic concepts like List, foreach, stream writing. Accessible to a beginner, safe code, but it'll churn memory (which is GC'd) and run using scalar CPU instructions.

Depending on your requirements you can then progressively enhance the memory churn, or the processing speed:

for(;;), async, LINQ, T[], ArrayPool, Span, NativeMemory.Alloc, Parallel.For, Vector, Vector256, System.Runtime.Intrinsics.

Eventually getting to a point where it's nearly the same as the best C code you could write, with no memory churn (or stop-the-world GC), and SIMD over all CPU cores for blisteringly fast performance, whilst keeping the all/most of the safety.

I think these new language features have the same virtue - I can opt into them later, and intellisense/analysers will optionally make me aware that they exist.

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();

The name ".NET" feels like it's from another era.

I think they would have done themselves a favor had they just rebranded as `dot`.

`dot build`

`dot run`

`dot publish`

`dot test`

Waaaaay better

I get that the language syntax is now (slightly) more regular.

But also, reading the code will mean keeping track of (slightly) more possible outcomes.

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#.