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

[Howard Lovatt]

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.