PROPOSAL: 'final' without explicit type

[Marek Kozieł]

2009/3/26 Reinier Zwitserloot <reinier at zwitserloot.com>:
> As Neal Gafter explained, lub (intersection type generator) will already
> find a common supertype if 1 of the intersection types is a supertype of all
> others. The notion of making the type 'the interface', if the intersection
> type contains exactly 1 interface, is a very bad idea. There is no precedent
> for this, and there are plenty of situations where this will go wrong. For
> example:
>
> final list = foo ? new LinkedList() : new ArrayList();
>
> the type of 'list' is what, exactly? Serializable? Cloneable? List? They're
> all valid, so that wouldn't work. If the feature says it will attempt to
> find a proper interface, people will wonder why that does not work.
>
> or, how about:
>
> final number = foo ? 5 : 10L;
>

"neither primitive"

> This will result in 'number's type being Serializable, which is completely
> wrong, because that's the only common interface. People would expect that to
> become 'Number', but it won't be, because Numer is a class and not an
> interface.
>
>
> finally, what's the wisdom in not allowing this for primitives? What's so
> bad about:
>
> final counter = 0;
>
>
>  --Reinier Zwitserloot
>
>

INTERSECTION:
It's no problem for me to forbid intersection here, or limit it to
situation when result type is 100% clear (at least for start):
final s = ( foo ? some : null );
final s = ( foo ? some : other ); // when one is ancestor of the second one.


PRIMITIVES:
I want this to be clear and make peoples think automatically:
     final + no type => Object
while primitives have not much common with Objects I'm against mixing them here.
-- 
Pozdrowionka. / Regards.
Lasu aka Marek Kozieł

http://lasu2string.blogspot.com/