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

[Tim Lebedkov]

Hello Maurizio,

(see my comments below)

On Wed, May 20, 2009 at 11:52 AM, Maurizio Cimadamore
<Maurizio.Cimadamore at sun.com> wrote:
> 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

In my opinion the JavaFX implementation is better: it is easier to implement and
more type safe. I'll add this example to the proposal.

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

It is clear that the compiler should generate an error in this case.
I'll add the example to the proposal.

Regards
--Tim

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