You know what really sucks?
When I have a method that returns a Foo and like 300 places it gets called.
And then I change it to return an ever so slightly different Bar
Ah, now I need to go and update the code in 300 places cause the return type changed.
“Can’t you just sed your codebase?”
Maybe, but it could cause some serious unintended dawizard
If it returned a “Foo”, whose structure changes in such a way as to requires changes in all places it was used…
That, sounds to me like a disaster you avoided by being helped (which is the polite way to describe developers not getting away with ignoring lazy and dangerous type conversion bugs) to fix each and every usage of it.
No, there’s countless ways code could be consuming a Foo or Bar and not care which.
Literally any form of serialization won’t care, for example.
Also you can change from a Foo to a Bar in a non breaking manner, where it’s name changed but the still have the same interface.
We’re talking about type inference, right?
If you have countless examples, I’d be happy to entertain others that have to do with type inference, because 1) serialisation is not related, 2) renaming in APIs is arguably, also not. Though, I cannot remember the last time my IDE wasn’t able to know, and do this for me.
The solution to this problem (and many others) is to use an IDE / editor which supports refactoring like that. Which is pretty much every IDE / editor unless you’re using some very obscure language I think.
I dont think external tooling should be a factor in deciding your language’s definition.