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.
Adding something is always gonna make things worse by default and has to be proven to be useful. Otherwise you have bloat and "yet another way of doing the one thing".
I'm a fan of this notation because it's consistent but language design should not just add features because it doesn't hurt.
I enjoy language features like this too. In fact, I love how languages like C# have handled nullability over the more recent years. No telling how many bugs I have prevented.
The only gripe I have though, is that I have to be remember which version does and does not support such syntax changes. It's not a major issue by any means, but when dealing with legacy applications, I tend to often forget what is and is not syntactically allowed.
“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...