PROPOSAL: 'final' without explicit type (update)

Derek Foster vapor1 at
Fri Apr 3 01:26:41 PDT 2009

-----Original Message-----
>From: Reinier Zwitserloot <reinier at>
>Sent: Mar 31, 2009 11:28 AM
>To: Tim Lebedkov <tim.lebedkov at>
>Cc: coin-dev at
>Subject: Re: PROPOSAL: 'final' without explicit type (update)
>This isn't the first time I've read about inferring types, and this  
>isn't the first time I've seen 'final' used for it.
>It's -not- just to avoid a new keyword. It's quite specifically  
>because auto-typing should only be done for final variables. The  
>problem is this:
> ...

This message had a good explanation of why final is preferred, and an explanation of why not using an interface type is probably OK in this limited circumstance. Probably the best explanations of these issues I've seen. (I've just snipped it away. Read the Reiner's original post for the original description.)

>FWIW, I'm -strongly- in favour of implicit typing for final local  
>method variables, and opposed to extending this for non-finals, not  
>just because its hard to come up with a syntax for it, due to there  
>being no readily available keywords or operators to do it with. :=  
>comes to mind, but that's about it.

I agree with this, on both points. (I'm perhaps not as "strongly" in favor as Reiner, but I do think that having implicit typing for local variables would be a net positive in readability, despite the lack of an explicit type in the code. I think that implicit typing would probably be a mistake for fields, however, even if they're final. (They're accessed in too many places.) With code that uses generics a lot, the overhead of having to mention long type names multiple times starts to become large. Improved type inference would help a lot.


More information about the coin-dev mailing list