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.

▲

ffsm8 5 days ago | parent [-]

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

▲

hahn-kev 5 days ago | parent | next [-]

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.

▲

ffsm8 5 days ago | parent [-]

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

	▲	moomin 5 days ago \| parent [-]
		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.

▲

rkomorn 5 days ago | parent | prev | next [-]

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.

▲

fakwandi_priv 5 days ago | parent | prev [-]

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.