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

Mon May 25 20:00:40 PDT 2009

I proposed the source keyword in an almost official coin proposal,  
waiting only on a few minor issues to be resolved, and that proposal  
got tarred, feathered, then hung by the neck until dead. Evidently, a  
'source' keyword isn't going to happen for coin, no matter how much we  
lobby for it. I took it as read that proposals are supposed to be  
halfway realistic, but in case that wasn't obvious:

The odds of 'auto' being introduced in Project Coin, or in fact, for  
any java 7 change, are zero.

> Cell<String> c = new( "Foo" );
>

Bad idea; you can't make that work if the LHS is an interface type,  
and yet very many java methodlocals and fields are in fact interfaces.  
The construct either can't be used, or leads to bad programming  
practice, such as :

ArrayList<String> l = new();

with ArrayList written out explicitly on the LHS just to make this  
syntax work. This is very bad; even if such a construct is final, the  
way the type is written out on the LHS explicitly suggests that the  
author intended for 'l' to be an ArrayList and not a List. I can live  
with this syntax for final variables, but I find 'final foo = new  
Type();' much more readable and it seems to me to fit better in how  
java works now.

> It is Tim's suggestion to make auto optional, rather than mine, but
> the way I read his suggestion was that there had to be a keyword
> already for auto to be optional.

It may be Tim's suggestion, but either way the notion of making 'auto'  
optional makes no sense to me: It could only possibly work for fields  
(whereas this is FAR more useful for method locals), AND it lacks  
consistency, AND it does not absolve the need for 'auto' (or some  
other keyword) to exist. What's the point of making 'auto' optional,  
then?

[snip: Whether auto behaviour is allowed for fields is a thing for  
expert groups]

Let's go back to realism for a moment: This list, and plenty of java  
polls in the past, have shown that any kind of type inference has some  
positive support, but plenty of detractors. 'auto' for fields is very  
unlikely to happen. Fortunately, there's -nothing- stopping java 8 or  
java 9 from adopting 'auto' behaviour for fields IF the community and  
experience with auto behaviour for method locals suggests its a good  
idea. Keeping the door open for such a future change requires no  
effort at all and does not impinge on the merits of this proposal  
(that is; no need to weaken its flexibility or syntax in order to make  
sure the future expansion remains an option). That's a lucky break -  
we should use it.

I really do like 'final foo = expr;' quite a bit, so I want it to  
succeed. It seems to me that taking it slow stands a very small chance.

Submit with just final and just method locals, and if an expert group  
determines its perfectly fine to extend this behaviour to non-finals  
or fields, they can make the changes themselves.

  --Reinier Zwitserloot

On May 26, 2009, at 03:23, Howard Lovatt wrote:

> Hi Reinier,
>
> General comment: I don't think the diamond proposal goes far enough
> and would like something along the lines of either:
>
> auto c = new Cell( "Foo" );
>
> or
>
> Cell<String> c = new( "Foo" );
>
> If only:
>
> final c = new Cell( "Foo" );
>
> made it - then this would at least be a step in the right direction.
>
> Detailed comments inline.
>
> 2009/5/26 Reinier Zwitserloot <reinier at zwitserloot.com>:
>> 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.
>
> That might be true, which is why I keep suggesting a source keyword to
> allow Java to move forward (see previous coin discussions)
>
>> '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;'
>
> Yes - auto should be a normal keyword
>
> [snip]
>
>> 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.
>
> See comment at end
>
>> NB: Howard, making 'auto' optional is a very bad idea, IMO. It  
>> wouldn't be
>> consistent:
>>
>> "a = 4;"
>
> It is Tim's suggestion to make auto optional, rather than mine, but
> the way I read his suggestion was that there had to be a keyword
> already for auto to be optional. Therefore the above example would be
> an assignment to an already declared variable rather than a variable
> declaration and hence no problem - Tim am I correct in this
> interpretation of your suggestion?
>
> [snip]
>
>> 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.
>
> This is the sort of detail an expert group could nut out. I don't
> think it is fundamental to the proposal. Personally I don't have this
> problem in typed languages with type inference, i.e. JavaFX, Scala,
> etc., and don't see this as a problem. This is a variation on Postel's
> Prescription (“Be liberal in what you accept, and conservative in what
> you send”), i.e. the return type, field type, and local type are all
> types of output therefore a specific class is fine - whereas a method
> argument should be an interface.
>
> -- Howard.
>
>>
>>
>>  --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.
>>>>
>>>
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit
>> http://www.messagelabs.com/email______________________________________________________________________
>>
>
>
>
> -- 
>  -- Howard.