Hacker News Reader

Comment by moomin | Hacker News Reader

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.

View on HN

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.

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.

Without it there's some silly inconsistency. For example I could call `person?.SetName(name)`, but if you wanted to refactor that into `person?.Name = name` you can't.

That's a great point I didn't think about. From that perspective, it does make sense.

Maybe my feeling is just rooted in the fact I've never used a language which allowed ?. on assignment

My take is that it’s pretty minor. Modern C# has across the board null checking and for the most part you’re not designing things where this even comes up. You are, however, correct, in that I have 100% seen the ?SetName thing used by devs who just wanted to make the null checker go away and didn’t actually think about what the correct behaviour was.

Reply on news.ycombinator.com