VERSION 2: Re: Proposal: Type inference for variable definition/initialization using the 'auto' keyword.

[Reinier Zwitserloot]

Why not drop the 'auto' keyword entirely? Using just 'final' has  
plenty of advantages:

1. No need to add a new keyword, which, lets face it, project coin is - 
NEVER- going to allow, ever. 'module' is okay because it's context  
sensitive, but auto cannot be. The following code:

auto x = 10;

is technically parsable right now, in java 1.6: It's like 'String x =  
10;' except instead of 'String' we have a type named 'auto', which is  
technically legal even though its against convention by having a type  
with a lowercase first letter.

2. No confusion around the following code:

auto list = new ArrayList();
list = new LinkedList(); //fail: LinkedList is not an ArrayList!

NB: It is infeasible to automagically detect that 'list' should be  
typed as just a List, and its quite a stretch for java to start  
considering ALL assignments and type the variable name with the  
intersection type(s). Compared to such antics, the rules for 'final'  
are much, much simpler: The type of the variable is the type of the  
RHS, unless the RHS is itself an intersection type, in which case for  
now we can just say such a construct isn't legal, and maybe later add  
support for intersection types for variables; such a change would be  
entirely backwards and migration compatible.

3. Less impactful; Assigning into a variable whose type is inferred  
from an expression is a much bigger deal than inferring the type of an  
unchanging reference. In the latter case, the link between the  
inferred type of a variable and its contents is obvious: It's the type  
of the content, period. In the former case, the type of a variable can  
be different from the content if you've reassigned, which leads to  
confusion.


NB: Howard, making 'auto' optional is a very bad idea, IMO. It  
wouldn't be consistent:

"a = 4;"

can now mean either: assign the result of expression '4' to the  
existing variable named 'a', and make sure the type of the expression  
is compatible with the type of 'a', OR: Create a new variable named  
'a', and infer the type off of the expression '4', then assign the  
result of that expression to it.

I -really- doubt java is the type of language to roll with creating  
variables on the fly when assigning to them, python-style. I rate the  
odds of that going into coin as 'when pigs fly'. Thus, we are stuck  
with inferring 'auto' only if there are OTHER keywords involved, but  
other than 'final', that never happens for method locals. Thus, you  
must be talking about type inference for fields, which is far too big  
a change for coin; consider:

1. Fields can be accessed outside of scope, which means the type  
information on the variable is much more important. Typing a list as  
'ArrayList' instead of a 'List' is a bad thing for a field, but only a  
very minor style incursion for a final method local, and yet outlawing  
'auto foo = new ArrayList();' seems arbitrary and wrong.

2. Even for a private field, where access is restricted to reflection,  
the scope of the field is much larger than for method locals, which  
considerably adds to the damage done by not being explicit about the  
type. For method locals, the places where the variable is used is  
usually fairly easy to spot (and if not, you should be splitting up  
your methods!). For fields, this is obviously not the case. You lose  
perspective of your inferred type.


  --Reinier Zwitserloot



On May 25, 2009, at 22:31, Tim Lebedkov wrote:

> Hello Howard,
> (Jeremy - FYI)
>
> I have thought about it also. It would be useful to make "auto"  
> optional.
> It was just not in the original proposal. And it would help (I'm not
> quite sure whether it is enough) with the "final" proposal from Jeremy
> Manson
> http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000009.html 
> .
>
> Making "auto" optional would also allow code like
>
> static a = "clouds";
>
> or
>
> private b = 44;
>
> I'm not quite sure yet whether I can change my proposal and about the
> implications and acceptance (and possible danger to the whole
> proposal) of this change.
>
> Regards
> --Tim
>
>
> On Mon, May 25, 2009 at 1:00 AM, Howard Lovatt  
> <howard.lovatt at iee.org> wrote:
>> The example:
>>
>> final auto list = new ArrayList<String>();
>>
>> seems strange, why not:
>>
>> final list = new ArrayList<String>();
>>
>> After all you are trying to reduce verbosity and making final
>> declarations the same length as variable ones will encourage people  
>> to
>> use final more, which is a good thing. The use of just final has been
>> proposed by many people for Java already, it won't break code.  Also
>> this final only construct is consistent with other languages e.g.
>> Scala, JavaFX, etc. that use def and var (final and auto
>> respectively).
>>
>>  -- Howard.
>>
>