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

[Maurizio Cimadamore]

Hi Tim
let me start by saying that I've been working on a similar area on the 
JavaFX compiler. As you probably know, JavaFX supports some kind of 
limited variable declaration type-inference, so that, e.g. a variable 
declared as:

var x = "Hello!"

is automatically inferred to be of type String.

Here's a bunch of problems that we found when implementing this feature 
in JavaFX - note I'm not saying that for these reason the proposal is 
not feasible, but I think that it should be more precise about the kind 
of things that the compiler should be able to infer. Let me clarify this 
by examples:

*) inference from multiple assignments:

often JavaFX users complain about the impossibility of writing code like:

var x = "Hello";
x = 1; //type-error here, Integer cannot be assigned to String

which means, after the type of the variable has been inferred (usually 
in the var initializer or in the first assignment to the variable) it is 
not possible to 'refine' the inferred type so that it also matches other 
assignments. In this case a 'complete' approach would have kept track of 
all the RHS {String, Integer} and inferred x to the type glb{String, 
Integer}, which happens to be Object & Comparable<? extends Object & 
Comparable < ... > >.

*) cycles in initialization preventing inference

In JavaFX forward references are allowed (with warning) which means that 
sometimes the compiler has no clue about which type should be picked 
given a sequence of statements like the following:

var x = y;
var y = x;

In Java we (luckily) have no such thing as forward reference - the 
compiler reports errors in such circumstances. However it's still 
possible to have some kind of cyclic dependency (through qualified 
static names):

class A {
static int a = B.b;
}

class B {
static int b = A.a;
}

The above code is legal and it compiles without errors. If we use the 
'auto' keyword we could write something like:

class A {
static auto a = B.b;
}

class B {
static auto b = A.a;
}

Which types is the compiler supposed to infer for both a and b?

I think that a proposal should deal explicitly with such 'corner' cases 
- they might seem a bit 'artificial' here, but they (or similar 
variants) are fairly common once users start to heavily rely on 
variable-type inference. Simply trusting the compiler to 'figure out' 
what the right type would be in each case is not an option :-)  .

Maurizio

Joseph D. Darcy 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
>
>