Re:JEP 286: Local-Variable Type Inference
by skippytheroo on Friday March 11, 2016 @01:08AM
(#11264933)
It will be caught as a compiler error. Since you would typically have the method signature declare that it returns the most general type it should be a non-issue. It's really no different from breaking code today by changing a method signature in an API.
Re:JEP 286: Local-Variable Type Inference
by wvenable on Thursday March 10, 2016 @04:03PM
(#11262279)
I think in practice this would be pretty rare. At least coming from a C# background it doesn't seem to be an issue I've ever encountered.
Re:JEP 286: Local-Variable Type Inference
by plesner on Saturday March 12, 2016 @01:51AM
(#11271662)
It's possible that it's more a theoretical than a practical problem, I would hope so. But it does seem to me like fundamentally a problematic property of a type system that having more accurate types can break your program. It's the static type equivalent of breaking the Liskov substitution principle.
Re:JEP 286: Local-Variable Type Inference
by wvenable on Saturday March 12, 2016 @08:58PM
(#11275769)
If a library author makes such a fundamental change their public API by making a method return more specific, I might actually want to know about it. I don't find it particularly problematic since it seems like code smell for that sort of change to happen in the first place.
Collection<String> getNames() { ... }
and in your code you do
var names = getNames(); if (...) names = Collections.emptySet();
Now, if the api later changes getNames() to be
List<String> getNames() { ... }
your code breaks. That's one of the advantages of only allowing this on final variables (besides reusing an existing keyword): it means this can't happen. Of course you already have a problem if the class has subclasses but I would argue that this is more subtle and problematic.