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

[Tim Lebedkov]

Hello Howard,

yes, you need

auto a=4;
of
final a=4;

a=4 is an assignment

Regards
--Tim

On Tue, May 26, 2009 at 3:23 AM, Howard Lovatt <howard.lovatt at iee.org> 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.
>