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...[0]: https://docs.avaloniaui.net/docs/basics/data/data-binding/co...
My big idea to fix WPF is to rebuild the data binding system to use the .NET compile-time code generation feature instead of run-time reflection. I think that would solve a lot of problems. For one, projects could do an actual AOT build of their applications (right now, you either need to rely on an installed .NET runtime or "publish" the project with a lot of .NET libraries included for self-extract, bloating the final file size). Code generation would probably improve performance quite a bit too, maybe open up the possibility to compile for cross-platform, introduce type safety for XAML bindings (rather than getting vague runtime binding errors), remove the need for so much class scaffolding, etc... I've thought about starting an open source project to do it myself, but seems like a pretty big task and I would essentially be starting a project to help with my other project which I already don't have enough time to work on...