Live data from Hacker News

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

blog.ivankahl.com

81–90 of 174 posts

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

#81
post #75
post #70

Earlier quoted context omitted.

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.

Still, enabling ?. Access on the left side of the equals (assigning) feels like a serious anti pattern to me I struggle to even see how anyone would prefer that over an explicit if before assigning. Having that on the right side (attribute reference) is great, but that was already available as far as I understood the post...

As someone who comes from a language with no ? (or equivalent) who only dabbles in C#, it actually seemed a little weird to me that this was one of the contexts where it wasn't usable.

So as a casual observer, I'd say it brings more consistency.

But also as a casual observer, my opinion is low-value.

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

#82
post #75
post #70

Earlier quoted context omitted.

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.

Still, enabling ?. Access on the left side of the equals (assigning) feels like a serious anti pattern to me I struggle to even see how anyone would prefer that over an explicit if before assigning. Having that on the right side (attribute reference) is great, but that was already available as far as I understood the post...

The point the article is trying to make is that it reduces boilerplate, wouldn't be surprised if this gets added to TS in the next year of two.

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

#83

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…

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

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

#84

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

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

#85
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 and less interested in what I used to consider my native language.

I used to write any and all little throwaway programs and utilities in C#, but it just keeps getting more and more fussy. Like Python, or maybe java. Nowadays I reach for C++. It's more complicated, but at least it's stable and not trying to rip itself apart.

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

#86

It's starting to feel like C# is going down the path of C++. Tons of features that introduce subtleties and everybody has their own set of pet features they know how to use. But the code gets really hard to understand when you encounter code that uses a subset you aren't familiar with. I remember staring at C++ codebases for days trying to figure out what is going on there. There was nothing wrong with the code. I ju…

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

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

#87

I’m having a hard time imagining where this is useful. If I’m trying to assign to a property, but encounter an intermediate null value in the access chain, just skipping the assignment is almost never going to be what I want to do. I’m going to want to initialize that null value.

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…

These null checks are actually for Optionals in the type system. The whole standard library and many better packages use nullability and thus indicate what can and cannot be null ever. And structs can never be null.

So no, c# are not constantly null-checking more than in Rust

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

#88

More concise? Yes. More readable? I'm less convinced on that one. Some of those edge cases and their effects can get pretty nuanced. I fear this will get overused exactly as the article warns, and I'm going to see bloody questions marks all over codebases. I hope in time the mental overhead to interpret exactly what they're doing will become muscle memory...

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

This is something I see in newbie or extremely lazy code. You have some nested object without a sane constructor and you have to conditionally construct a list three levels down.

This is a fantastic way to make such nasty behavior easier.

And agreed on the question mark fatigue. This happened to a project in my last job. Because nullable types were disabled, everything had question marks because you can't just wish away null values. So we all became blind and several nullref exceptions persisted for far too long.

I'm not convinced this is any better.

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

#89
post #53

Is .NET entering its twilight years as a tech people build new things with? I just can't imagine Gen Z wanting to start a project in C#. I realise there are still .NET shops, and I still talk to people who do it daily, but ours is a field driven by fashion whether we care to admit or not - and C# just does not feel as fashionable as it once did (I'm a former C# dev, up until 2020)

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.

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

#90

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…

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.

Post reply on HN