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

[Joseph D. Darcy]

Hi Tim.

Tim Lebedkov wrote:
> Hello Joe,
>
> see my comments below
>
> On Fri, May 15, 2009 at 7:40 AM, Joseph D. Darcy <Joe.Darcy at sun.com> wrote:
>   
>> Tim Lebedkov wrote:
>>     
>>> Type inference for variable definition/initialization using the 'auto'
>>> keyword.
>>>
>>> AUTHOR(S): Tim Lebedkov
>>>
>>> OVERVIEW
>>>
>>> Provide a two sentence or shorter description of these five aspects of
>>> the feature:
>>>
>>> FEATURE SUMMARY: Should be suitable as a summary in a language tutorial.
>>>
>>> This proposal addresses the addition of type inference for
>>> variable definitions to the Java programming language using the 'auto'
>>> keyword instead of specific type name.
>>>
>>> For example, consider the following assignment statement:
>>>
>>> Map<String, List<String>> anagrams = new HashMap<String, List<String>>();
>>>
>>> This is rather lengthy, so it can be replaced with this:
>>>
>>> auto anagrams = new HashMap<String, List<String>>();
>>>
>>> and anagrams is automatically typed as HashMap<String, List<String>>
>>>
>>> MAJOR ADVANTAGE: What makes the proposal a favorable change?
>>>
>>> Generics have had a tremendously positive impact on type safety in the
>>> Java programming language. They  have made it possible to provide
>>> static guarantees about the type of instances used by other classes,
>>> preventing entire classes of runtime errors from occurring. However,
>>> generics have added complexity to Java, making the code far more
>>> verbose and occasionally difficult to read. Although solving this
>>> problem is well outside the scope of this proposal, a limited form of
>>> type inference would remove unnecessary redundancy from the language.
>>> Even without generics it seems unnecessary to duplicate type names for
>>> simple variable definitions/assignments like:
>>>
>>> Integer a = new Integer(1023);
>>>
>>> MAJOR BENEFIT: Why is the platform better if the proposal is adopted?
>>>
>>> Less code and no duplication has a positive impact on many things:
>>> - faster typing/faster code changes
>>> - easier code changing without IDE assistance
>>> - code versioning diffs are more clear
>>>
>>> MAJOR DISADVANTAGE: There is always a cost.
>>>
>>> - it could be harder to read the code.
>>> - auto will be a keyword and may break some old code
>>>
>>> ALTERNATIVES: Can the benefits and advantages be had some way without
>>> a language change?
>>>
>>> no
>>>
>>>
>>>       
>> Catching up on proposal comments, I think the core benefits of using "auto"
>> or "final" on the left hand side for variables are achieved with the diamond
>> operator that allows one to elide type parameters on the right hand side.
>>  IMO, the diamond solution of specifying the variable type fully on the left
>> and then specifying only the implementation type without redundant, repeated
>> type parameters on the right is more in keeping with Java coding style.
>>
>> -Joe
>>
>>     
>
> your statement "the core benefits ... are achived with the diamond
> operator" is just not true.
> As an example I picked 2 classes from Java 6: java.util.ArrayList and
> javax.management.ObjectName. "auto" can be useful in 3% or 4.5% of
> code lines respectively (and this including comments and whitespace!).
> Whereas "diamond" in 0% and 0.09%!
>   

Two classes is not a statistically significant sample and choosing 
ArrayList is not a very representative choice since the implementation 
of a collection class is much less common than the use of a collection 
class.

> "diamond" just cannot help with something like: TableModel m = new
> JTable().getModel();
>
> Your second statement about "keeping Java coding style" is completely
> unclear to me. Why is
>
> List<String> a = new ArrayList<>();
>
> more "Java" than this:
>
> auto a = new ArrayList<String>();   ?
>   

Because the Java coding style has been designed to explicitly (and 
statically) declare the type of variables on the left hand side and 
choose the implementation type on the right hand side.

The diamond pattern preserves all the explicit, textual typing 
information on the left and keeps the essence of the implementation 
choice on the right without the clutter of repeated type variables.

-Joe