Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.ivankahl.com

Post reply on HN
Print view View original

61–70 of 174 posts

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

#61

Post by zdragnar »

Quarrelsome wrote: post #39
bandyaboot wrote: post #31

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…

Unfortunately, I suspect this will just makes it easier to keep writing sloppy code.

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

#63

Post by Dylan16807 »

kazinator wrote: post #13

Null conditional assignment is bunk. When you have an expression P which names a mutable place, and you execute P := X, the contract says that P now exhibits the value X, until it is assigned another value. Conditional assignment fucks this up. When P doesn't exist, X is not stored. (Worse, it may even be that the expression X is not evaluated, depending on how deep the fuckery goes.) Then when you access the same ex…

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.

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

#64

Post by chowells »

mkoubaa wrote: post #44
bandyaboot wrote: post #31

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.

Monad-maxxing has ruined many a language

This is a functor, not a monad. Also, it's implemented really poorly. If only more languages actually implemented monads well. You wouldn't need special case junk like this.

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

#66

Post by kazinator »

Dylan16807 wrote: post #63
kazinator wrote: post #13

Null conditional assignment is bunk. When you have an expression P which names a mutable place, and you execute P := X, the contract says that P now exhibits the value X, until it is assigned another value. Conditional assignment fucks this up. When P doesn't exist, X is not stored. (Worse, it may even be that the expression X is not evaluated, depending on how deep the fuckery goes.) Then when you access the same ex…

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

Someone is going to run into a null exception in an assignment and just throw in the question mark to shut it up, not thinking about the value disappearing.

That's the mindset the feature is developed for (and by).

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

#67

Post by garbagepatch »

kazinator wrote: post #28
esafak wrote: post #19

Earlier quoted context omitted.

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

False dichotomy. The problem is that the syntax implements a solution that is likely wrong in many situations and pairs with a bad program design. Maybe when we have this: what?.could?.possibly.go?.wrong = important_value() Maybe we want code like this: if (!what) what = new typeof(what); // default-construct representative instance if (!what.could) what.could = new typeof(what.could); if (!what.could.possibly.go) wh…

I wonder, does the important_value function get called and the value discarded or never called at all? Looks like a footgun if it has side-effects.

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

#68

Post by vjvjvjvjghv »

jayd16 wrote: post #54
vjvjvjvjghv wrote: post #32

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…

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

Agreed about the syntax choices. Much better than C++. The language is just getting a little too big for my taste.

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

#69

Post by larusso »

rkagerer wrote: post #14

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

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.

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

#70

Post by moomin »

peterashford wrote: post #47

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.

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.
Post reply on HN