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

41–50 of 174 posts

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

#41

Post by moogly »

layer8 wrote: post #38
moogly wrote: post #34

Earlier quoted context omitted.

I'm also not sure I have a lot of code where this would be useful, but adding it to the language I don't feel makes it worse in any way; in fact, it makes it more consistent since you can do conditional null reads and conditional null method invocations (w/ `?.Invoke()`), so why not writes too.

“Why not?” is never a good-enough reason to add a new language feature. If it’s rarely used, people may misinterpret whether the RHS is evaluated or not when the LHS doesn’t exist (I don’t actually know which it is). Optional operations and missing properties often require subtle consideration of how to handle them. You don’t want to make it too easy to say “whatever”.

> people may misinterpret whether the RHS is evaluated or not when the LHS doesn’t exist

I fully expect no RHS evaluation in that case. I think the fear is misplaced; it's one of those "why can't I do that when I can do this" IMO. If you're concerned, enable the analyzer to forbid it.

There are already some really overly paranoid analyzers in the full normal set that makes me wonder how masochistic one can be...

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

#43

Post by DimmieMan »

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

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 marks all over the codebase most of us are going to stop transpiling them in our head and start subconsciously filtering them out and miss a lot of stupid mistakes too.

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

#44

Post by mkoubaa »

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

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

#46

Post by Quarrelsome »

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…

NullReferenceException, in line 7.

you didn't null check possibly.go.

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

#48

Post by Merad »

LAC-Tech wrote: post #40

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've been using .Net for almost 20 years, professionally for half that time, and I feel like excitement and momentum in the community has only been increasing.

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

#49

Post by tekdude »

I wonder if this supports a cleaner way to throw when the target property's parent object is null? With null-coalescing assignment, you can do the following which will throw when 'x' is null:

  string x = null;
  string y = x ?? throw new ArgumentException("x is null");
It would be interesting to try something like:

  customer?.Name = newName ?? throw new InvalidOperationException("customer is null");
But I don't know how the language would be able to determine which potential null it was throwing for: 'customer' could be null, but so could 'newName'. I guess... maybe you could do:

  (customer ?? throw new InvalidOperationException("customer is null")).Name = newName ?? throw new ArgumentException("newName is null");
But the language already supports that, and it's extremely ugly...

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

#50

Post by koyote »

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…

There's a couple reasons I disagree with you on this (at the moment; as given enough time I am sure C# will also jump the shark):

* The above is just applying an existing (useful) feature to a different context. So there isn't really much learning needed, it now just 'works as expected' for assignments and I'd expect most C# engineers to start using this from the get go.

* As a C# and C++ developer, I am always excited to hear about new things coming in C++ that purportedly fix some old pain points. But in the last decade I'd say the vast majority of those have been implemented in awful ways that actually make the problem worse (e.g. modules, filesystem, ...). C#'s new features always seem pretty sound to me on the other hand.

Post reply on HN