▲ | Dylan16807 5 days ago | |||||||||||||||||||||||||
A representative config.connection being made out of nothing sounds pretty bad to me. If you want to make sure the value doesn't disappear, you shouldn't be using conditional assignment in the first place. The config example isn't the best, but instead imagine if it was just connection.?retryPolicy. After you set connection?.retryPolicy it would be weird for reading it back to be null. But it would be just as weird for connection?.retryPolicy to not be null when we never established a connection in the first place. The copy on write analogy is tempting but what you're describing only works when the default value is entirely made of nulls. If you need anything that isn't null, you need to actually make an object (either upfront or on first access). And if you do that, you don't need ?. anymore. | ||||||||||||||||||||||||||
▲ | kazinator 4 days ago | parent | next [-] | |||||||||||||||||||||||||
> If you want to make sure the value doesn't disappear, you shouldn't be using conditional assignment in the first place. If it worked using "materialize-on-write" semantics, why wouldn't you, as an alternative to the verbose code which checks every path component that might not exist, and instantiates it before doing the assignment? Obviously, you can't use it if you don't have materialize-on-write semantics in the assigned expression not that you shouldn't. | ||||||||||||||||||||||||||
| ||||||||||||||||||||||||||
▲ | kazinator 5 days ago | parent | prev [-] | |||||||||||||||||||||||||
Someone is going to run into a null exception in an assignment and just throw in the question mark to shut it up, not thinking about the value disappearing. That's the mindset the feature is developed for (and by). |