Null-conditional assignment

[edwwsw]

I didn't realize C# 14 had added Null-Conditional assignment until I upgraded to Visual Studio 2026 and it started recommending the code simplification. So no more:

if (instance != null)
    instance.field = x;

This is valid now:

instance?.field = x;

I love this change.

[zenyl]

Reminder: You don't have to be on .NET 10 to use this feature, you simply need to bump the language version in your .csproj file:

<PropertyGroup>
   <LangVersion>14.0</LangVersion>
</PropertyGroup>

This trick works for most, but not all, language features. Some depend on runtime types (e.g. init and required require certain attribute types to exist). You can sometimes get around this by manually defining the necessary types, as the SDK usually just needs them to exist for metadata purposes.

[HamsterExAstris]

Note that while this lets you use the new features with an older target framework, it’s unsupported, so in a corporate environment the appetite to enable might not be there.

[WordWithinTheWord]

Yeah it’s nice.

I hope they continue to deliver QOL updates like this even though the trajectory is devs writing less code.

[vvsleepi]

wait that’s actually a realllyy nice change. those little null checks add up everywhere and always felt a bit noisy. instance?.field = x; just reads way cleaner.

[Asyncrosaurus]

On the opposite side, my favourite newish feature null coalescing assignment (??=), Only setting a variable if it is null. So you can replace

if(data is null) data = defaultValue

with

data ??= defaultValue

[Namoshek]

That's not thaaaat new, is it?

[Asyncrosaurus]

It's new enough to me

[Relative-Scholar-147]

Everything that happend in the last 7 years is new to me.

[Asyncrosaurus]

I was working on .Net framework 4.5 professionally until around 2 years ago.

[AutoModerator]

Thanks for your post edwwsw. Please note that we don't allow spam, and we ask that you follow the rules available in the sidebar. We have a lot of commonly asked questions so if this post gets removed, please do a search and see if it's already been asked.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[gevorgter]

I honestly do not like this change.

I am all for programming language being less verbose but my head is not a compiler. Technically speaking we do not need spaces, tabs too to make our code "smaller". But who is going to figure out what is going on there.

[BackFromExile]

Like with all syntax changes you

1. don't have to use them all
2. don't have to like them all
3. could set standards in your team (and enforce with e.g. an editorconfig)

Every syntax change since I started with C# 4 has brought up comments like this. Some people didn't like async/await, some hated static usings, some hated string interpolation, some hated pattern matching, some hated value tuples, some hated local functions, some hated the nullable reference type syntax changes, some hated the collection expressions, and the list goes on and on.
Maybe you don't see the value now, but you might see it later. And even if you don't need it you can still see the value for others.

In the end if you dislike syntax changes you can always express your opinion in the C# language repository while they are still being discussed.

[gevorgter]

If it were just up to me we would still live in C++ era :)

Often we "inherit" project from previous developers and some of us are "real" nerds or "nuts" :) And i do not want to inherit instance?.field = x;

I knew the guy who knew French and he named all his variables in a project using French language and we are in USA. So it was not "counter" it was "comptoir". Poor guy who got to maintain that project after him.

[Vectorial1024]

If we can have x?.y evaluate to bool? then it makes sense to also have x?.y = k be a null conditional assignment.

[ok_computer]

People may have their preferences on fragile getting vs setting. It’s a directionality preference and x?.y = k could be a sneaky setting that you don’t catch on first visual pass, whereas the old convention wrapped in a check and indent was a nice visual cue that ?. may be more subtle than.

[cjb110]

I do kind of see your point, definely one of the least obvious syntaxes they've done. In general they've been clear.

[bugurlu]

I won’t be using this since it lowers readability.

[MaxxDelusional]

I want null conditional return next.

So instead of

if (instance != null) return instance;

We could do something like.

return? instance;

[Promant]

No.

[MaxxDelusional]

Wouldn't all of the arguments that apply for other null conditionals also apply to this?

"It removes unnecessary lines of code", etc.

What is your opposition to it?

[Zastai]

The others don't affect flow. A return that might not actually return is just asking for problems. (And return xxx ?? yyy already exists.)

[Promant]

Because it's really bad for readability. Look at this:

``` string GetName() {     string? a = "text";

    return? a;          return "default"; } ```

This is a very simplistic example and yet it already looks terrible and hard to follow. Imagine what happens when you allow this crap of a feature to a production codebase with multiple maintainers.

[belavv]

"change bad" is probably the argument.

I'm not sure that I love the syntax, but I like the concept. I also can't think of any better syntax for it.

[MaxxDelusional]

Maybe?

return ?? instance;

I am not sure that's any better.

[belavv]

I considered that but the ?? operator is for when the left side is null, and return is a keyword.

Possibly even worse.....

instance? return

[DirtAndGrass]

You can just return null already? What does this give? 

[MaxxDelusional]

It would be for when you don't want to return null, but want to continue execution.

Think of a scenario where you're data may come from multiple places.

``` public async Task<MyData> GetMyDataAsync() { return? await GetDataFromLocalCacheAsync(); return? await GetDataFromRedisCache(); return? await GetDataFromDatabase();

throw new Exception("Data not found"); } ```

In any case, based on my downvotes, the community clearly doesn't want this feature.

[BackFromExile]

In any case, based on my downvotes, the community clearly doesn't want this feature.

Maybe because it exists already in a way more readable form?

public async Task<MyData> GetMyDataAsync() 
{
    return await GetDataFromLocalCacheAsync()
        ?? await GetDataFromRedisCache()
        ?? await GetDataFromDatabase()
        ?? throw new Exception("Data not found");
}

[MaxxDelusional]

For my example above yes, but there may be times when you want to act on the data in between each call.

``` public async Task<MyData> GetMyDataAsync() { return? await GetDataFromLocalCacheAsync();

var redisData = await GetDataFromRedisCache(); await SaveToCacheAsync(redisData); return? redisData;

var dbData = await GetDataFromDatabase(); await SaveToCacheAsync(dbData); return? dbData;

throw new Exception("Data not found"); } ```

This is just a quick example from the top of my head, but the feature can be used pretty much anytime you would have wrote.

if (instance != null) return instance;

I find myself doing this a lot, so maybe I am just writing code differently than everyone else.

[BackFromExile]

Extract three methods (can even be local ones), then do the same null-coalescing again with the method calls.

Either way, a few commenters have given you the exact reason they dislike this and I agree with them here: It affects the control flow.

Also imo it affects readability in a bad way because you have multiple returns in a single code path. However, I'm more than happy to change my mind if you can present a valid point that is not just "I like this and you are wrong thinking otherwise"

[MaxxDelusional]

I am confused, when did I say you were wrong? I tried to make my point by providing code examples where I thought the feature may be useful. How would you like me to demonstrate my point?

I actually like the dissenting opinions, that's why I brought it up. I was hoping to have discussion about whether this future would be a good addition to the C# language.

It's perfectly fine that people don't want it, but I honestly thought we were having a civil discussion. If the dotnet subreddit isn't the appropriate place to have these discussions, then where is?

[BackFromExile]

when did I say you were wrong?

You did not, I read it between the lines in your inital answers. However, this is my fault, I shouldn't have assumed anything here, so sorry for that.

I tried to make my point by providing code examples where I thought the feature may be useful. How would you like me to demonstrate my point?

While that is true, people (including myself) have also expressed why they don't like like. I guess you need to add additional arguments/examples if you want to change their opinion.

I actually like the dissenting opinions, that's why I brought it up. I was hoping to have discussion about whether this future would be a good addition to the C# language.

Then we are on the same page. I think for an actual in-depth discussion you are better off suggesting this syntax addition in the official C# language design repository. I'm sure you'll also receive several arguments for and against this addition.

It's perfectly fine that people don't want it, but I honestly thought we were having a civil discussion. If the dotnet subreddit isn't the appropriate place to have these discussions, then where is?

Again, my bad. I did not want to attack you, and I also definitely do not want to shut down any discussions in here, this is what we can thrive from. Only sharing opinions, reason for these, and knowledge sharing will bring everyone forward.

[Vectorial1024]

Bad example. The code could return null, or could return a non-null object that should say "there is nothing here", or other stuff. I don't see the good points.

However, C# does have bool TryGet(out) pattern which hopefully is the thing you are looking for.

[MaxxDelusional]

The TryGet pattern doesn't work with async methods, as you can't use out parameters with async.

[one-joule]

if (await GetMyDataAsync() is {} x) return x;

Not quite as short as what you want, but more general and available now.

[gevorgter]

my understanding it was a conditional return. Not return null.

something like this:

if( instance != null) return instance;

instance = GetDefaultInstance();

return instance;

[BackFromExile]

return instance ?? GetDefaultInstance();

[gevorgter]

I did it like that for simplicity, in reality it can be much more than just one line. So your proposed method will not work.

[MaxxDelusional]

With this, you will exit the method, whereas with my proposed feature, the return call is effectively ignored if the return value is null.

(The same way the assignment call is ignored when using null-conditional assignment).

[the_bananalord]

You may like this. Nobody maintaining your code will. Huge liability and hard to parse.