I'm working on a Unity game and I'm so annoyed I can't use all of the new fancy c# features
What's New in C# 14: Null-Conditional Assignments
21–30 of 174 posts
Re: What's New in C# 14: Null-Conditional Assignments
#22More 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...
Oh come on just learn it properly it's not a big deal to read it
Re: What's New in C# 14: Null-Conditional Assignments
#23Re: What's New in C# 14: Null-Conditional Assignments
#24More 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...
What?.could?.possibly?.go?.wrong?.
Nothing to worry about:
What?.could?.possibly?.go?.wrong?
What?.could?.possibly?.go?.wrong = important_value()
Re: What's New in C# 14: Null-Conditional Assignments
#25So like ruby's '&.' null safe chaining
Re: What's New in C# 14: Null-Conditional Assignments
#26At least so far, my instinct is that we should turn this off/ ensure it is never turned on, as it seems likely to be a foot gun.
I couldn't imagine what a "Null-Conditional Assignment" would do, and now I see but I don't want this.
Less seriously, I think there's plenty of April Fools opportunity in this space. "Null-Conditional Function Parameters" for example. Suppose we call foo(bar?, baz?) we can now decide that because bar was null, this is actually executing foo(baz) even though that's a completely unrelated overload. Hilarity ensues!
Or what about "Null-Conditional Syntax". If I write ???? inside a namespace block, C# just assumes that when we need stuff which doesn't exist from this namespace it's probably just null anyway, don't stress. Instead of actual work I can just open up a file, paste in ???? and by the time anybody realises none of my new "classes" actually exist or work I've collected my salary anyway.
Re: What's New in C# 14: Null-Conditional Assignments
#27Earlier quoted context omitted.
if (This) { if (is) { if (much) { if (better) { println("I get paid by the brace") } } } }
if (!same) { return; } if (!number) { return; } if (!of_braces) { return; } println("but easier to read")
Yes, you should definitely unnest functions and exit early. But the null-coalesced version is shorter still.
Re: What's New in C# 14: Null-Conditional Assignments
#28Earlier quoted context omitted.
What?.could?.possibly?.go?.wrong?.
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()
if (!what)
what = new typeof(what); // default-construct representative instance
if (!what.could)
what.could = new typeof(what.could);
if (!what.could.possibly.go)
what.could.possibly.go = new typeof(what.could.posssibly.go)
// now assignment can take place and actually retain the stored value
// since we may have allocated what, we have to be sure
// we propagate it out of here.
what.could.possibly.go.wrong = important_value();
Why would you ever write an assignment, but not expect that it "sticks"? Assignments are pretty important.
What if someone doesn't notice the question marks and proceeds to read the rest of the code thinking that the assignment always takes effect? Is that still readable?
Re: What's New in C# 14: Null-Conditional Assignments
#29Isn't this more confusing? Because it skip the code if the value is null and I don't think it is normal to follow the flow assuming nothing has happened.
> I don't think it is normal to follow the flow assuming nothing has happened. I think it is for situations where the programmer wants to check a child property but the parent object may be null. If the parent is expected to be null sometimes, the syntax lets the programmer express "try to get this value, but if we can't then move on" without the boilerplate of explicitly checking null (which may be a better pattern…
Your summary is almost correct but replace where you used "get" with "set".
Re: What's New in C# 14: Null-Conditional Assignments
#30More 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...
Swift has had this from the beginning, and it doesn’t seem to have been a problem.