The Number case (which meshes together the problems of changing return types, fundamental vs non-fundamental types, and numerical precision) is the most interesting one, that's why I gave my opinion on that. 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 ;-) ). (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 ;-) )). -------- Ursprüngliche Nachricht --------Von: Jochen Theodorou <[email protected]> Datum: 07.09.18 09:03 (GMT+01:00) An: MG <[email protected]>, [email protected] Betreff: Re: About type inference of method return value On 06.09.2018 20:51, MG wrote: [..] > The "int to long" inference example is an interesting special case that > I think would need to be discussed*: We could either reject these case > (throw CTE) - or maybe inferring to a higher up super type (Number in > the extreme case) could sort of work... > But due to inherently involved performance/precision issues, in my > opinion inferring number types does not seem like a good idea...
I could have made the example differently and let it return a different "incompatible, but fitting" type. You should not get too hang up on the specific types in use, but look more at the secondary effects the change has bye Jochen
