On 07.09.2018 19:24, mg wrote: [...]
The general, changing-return-type-only case for me falls under the responsibility of the developer: He will have to decide whether using type inference is the right choice here, and fix any potential future errors that might occur if the inferred type changes. If you use inference everywhere, you should not be surprised if a change in one place leads to a domino cascade of type errors in other places - and you should ask yourself, if you should not go def / duck typing (ie dynamic Groovy) all the way, if you dislike giving types explicitely so much... (which in practice will often mean that your IDE will do the type inference for you ;-) ).
why should we add a change, that will shorten programs and falls perfectly in to the lazy developer realm, just to advice not to use it? This is different from adding a special feature, for which you have to do special things. I expect this to be used by default by many people.
(Using the new var (and existing final without an explicit type) will reduce the cascading type change problem in some cases - whether it leads to more readable code is a different question (although it will still be more readable than having dynamic style def everywhere ;-) )).
lets take the new final for example. Having the ability to not to write final will lead people to not to write final by default (unless they make everything final anyway, which some do). But this is ok. Not using final for cases that are final will then not lead to a problem. Not using final for cases where you need final and that are not final, will still lead to a compilation error. I don't see a real drawback from the optional final.
"var" is a bit a different story. It will lead to surprising types being used and partially violates the paradigm that you should not use the most special class for your variables if not needed. But even then the effect is quite local. If you keep your methods small, as you should anyway, then there is not much of a disadvantage here to be seen in my opinion. But it already makes the program less readable for another user. It is the same in dynamic Groovy with def... Which shows you simply have to learn to read the method differently. But the effect is very localized.
Now return type inference is not, as I have shown already. And that, plus the lazy developer part, is why I am not friend of this.
bye Jochen
