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

[Tim Lebedkov]

Hello Joe,

see my comments below

On Fri, May 15, 2009 at 9:21 PM, Joseph D. Darcy <Joe.Darcy at sun.com> wrote:
> 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.

You're right. These two classes are not statistically significant, but:
- number of lines where "auto" can be used is always >= the number of
lines where "diamond" can be used
- you have probably written many thousands of lines in Java. Don't you
have at least the feeling that there are at least 3-5 times more
  variable definitions without object creation than with it?
- (in case you do not have such feeling :-) I'd try to count lines on
a larger source base.

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

OK. I didn't know that Java was designed to explicitly declare the
type of variables on the left hand side,
but even if it was, it's worth changing.

Regards
--Tim

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