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

[Tim Lebedkov]

Hello Reinier,

see my comments below

On Tue, May 26, 2009 at 2:12 AM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> Why not drop the 'auto' keyword entirely? Using just 'final' has plenty of
> advantages:

I assume you know about the main disadvantage, but I'll write it one more time:
You cannot define a mutable variable using "final".

>
> 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.
>

I hope we can have a new keyword :-)

> 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.
>

compiler should probably generate 2 errors for the second line here:

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

1st error: you cannot assign a new value to a final variable
2nd error: incompatible types

It seems "final" instead of "auto" has no real advantage here


> 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.
>

If "auto" is more "impactful", then in a very small degree.

>
> 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:

you'll need either

auto a = 4;
or
final a = 4;

a = 4 is an assignment

>
> 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.

the usage of instance fields outside of the declaring class are rare.
Additionally we have at least 3 sources for the type information:
- JavaDoc
- .class files
- IDE

Regards
--Tim
>
>
>  --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.
>>>
>>
>
>