Live data from Hacker News

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

blog.ivankahl.com

111–120 of 174 posts

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

#111

I'm a Java fan so I'm contractually required to dis c#, but actually I kinda like this. It reduces boilerplate. Yes, it could be abused but this is what code review is for.

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.

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

#112
While I can understand the reason behind the behaviour I cannot find it intuitive.

If I say an asseignment I expect the value to be "evaluated".

I could have grasped the expression in all the null values would have been replaced with new instances, but then it would have been too much invasive and magic to work, so - again - I understand why the designers night have been force to settle for the actual behaviour...

But maybe then the half-solution is not worth it

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

#113

I don't really get this obsessive insistence of purging the language of null checks. (And "if(x is not null)" is not an improvement of any kind) It feels like Microsoft just wants C# to be Python or whatever and the language is losing its value and identity. It's becoming bland, messy, and complicated for all the same reasons they keep increasing padding between UI elements. It's very "me too" and I'm becoming less a…

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.

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

#114
post #53

Earlier quoted context omitted.

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 t…

I personally can't think of an all-rounder language that is better than C# I didn't ask about whether it was good. I asked about whether it's past its peak.

It's certainly reaching "maturity". And I'd say it's improving still but the improvements are small (which is expected at that point).

I wouldn't say it's past its peak because it's still improving and there is no good alternative for a language of its class. Go isn't it (I doubt there will be a good desktop/mobile app/game engine etc story for Go in the future). Swift could have been a competitor in the allround space but Apple doesn't seem interested in conquering the world outside its own garden. I'm not sure who it would be that would make the "next" C# and .NET. Only Microsoft and Apple are making commercial desktop environments, for example.

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

#115
Thanks for the upvotes! While testing and writing about the feature, I suspected it would receive mixed reactions.

The `?.` operator behaves similarly on the LHS to the RHS, making the language more consistent, which is always a good thing. In terms of readability, I would say that once you understand how the operator works (which is intuitive because the language already supports it on the RHS), it becomes more readable than wrapping conditionals in `if` statements.

There are downsides, such as the overuse I mentioned. But this is true for many other language features: it requires experience to know when to use a feature appropriately, rather than applying it everywhere.

However, the great thing about this particular enhancement is that it's mostly cosmetic. Nothing prevents teams from not adopting it; the old syntax still works and can be enforced. C# and .NET are incredibly versatile, which means code can look dramatically different depending on its context and domain. For some projects, this feature might not be needed at all. But many codebases do end up with various conditional assignments, and in those cases, this can be useful.

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

#116

Earlier quoted context omitted.

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 t…

> his actually _reduces_ the "mental size" of C# IDK, if you read Settings?.RetryPolicy = new ExponentialBackoffRetryPolicy(); as "there is a now a ExponentialBackoffRetryPolicy" then you could be caught out when there isn't. That one ? char can be ignored .. unless it can't. It's another case where "just because it compiles and runs doesn't mean that it does the thing". This to me is another thing to keep track of.…

The description mentions side effects such as GetNextId(), but creating that object doesn't look like it has any side effects, so perhaps not the best example.

As I wrote in another comment, ignored side effects are perhaps the one questionable aspect of it. I usually assume RHS is evaluated first, regardless of what happens on the left - but I'm not sure that mental model was actually correct. But keeping that would mean having to simply do explicit if _when_ there are side effects. So

    if (myObj is not null)
       myObj.Id = GetNextAvailableId(); // Side effect
But for non-side effects

    Settings?.RetryPolicy = new ExponentialBackoffRetryPolicy();
It's obviously hard to know when there are side effects, but that problem already existed. You could trip this up before too e.g.

    var id = GetNextAvailableId();
    if (myObj is not null)
       myObj.Id = id;
Would have tripped you up. But at least it's obvious WHY it would. Something I have long sought in C# is a good way of tracking what is pure and what isn't.

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

#118

Cute, but is this actually needed? It's one more thing to remember, one more thing to know the subtleties of, and for what? To save writing a very readable and unambiguous line of code? It feels like the C# designers have a hard time saying "no" to ideas coming their way. It's one of my biggest annoyances with this otherwise nice language. At this point, C# has over 120 keywords (incl. contextual ones) [0]. This is a…

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.

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

#119

Earlier quoted context omitted.

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 t…

> his actually _reduces_ the "mental size" of C# IDK, if you read Settings?.RetryPolicy = new ExponentialBackoffRetryPolicy(); as "there is a now a ExponentialBackoffRetryPolicy" then you could be caught out when there isn't. That one ? char can be ignored .. unless it can't. It's another case where "just because it compiles and runs doesn't mean that it does the thing". This to me is another thing to keep track of.…

Hi there! One of the lang designers here.

That's been part and parcel for C# for over 10 years at this point. When we added `?.` originally, it was its nature that it would not execute code that was now unnecessary due to the receiver being null. For example:

    Settings?.SetRetryPolicy(new ExponentialBackoffRetryPolicy());
This would already not run anything on the RHS of the `?.` if `Settings` was null.

So this feature behaves consistently with how the language has always treated this space. Except now it doesn't have an artificial limitation on which 'expression' level it stops at.

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

#120

While this is nice, there are some long requested features like Discriminated Unions that got delayed a lot.

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.

Post reply on HN