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

[Reinier Zwitserloot]

IDE automatizations are one way. I can let eclipse generate all my  
toString, getters, constructor, hashCode and equals boilerplate for  
me, but once eclipse generates pagefuls of noise, that noise will no  
longer be going away. The same happens, though with smaller effect,  
when you let your IDE turn:

new HashMap<String, List<Set<Integer>>>();

into:

final Map<String, List<Set<Integer>>> foo = new HashMap<String,  
List<Set<Integer>>>();

instead of:

final foo = new HashMap<String, List<Set<Integer>>>();


or even:

final FileInputStream fis = new FileInputStream(fileName);

versus:

final fis = new FileInputStream(fileName);


However, FWIW, yes, having intersection types would be nicer, and  
generating a compiler error when there's no singular top type is  
probably far too confusing in the first place. So, yes - amend my  
suggestion to state that intersection types are much preferable to  
copping out when the RHS doesn't translate neatly to a single type.

  --Reinier Zwitserloot



On May 26, 2009, at 15:56, Joe Kearney wrote:

> It seems to me that to restrict auto variables not to be  
> intersection types misses the most useful applications of a proposal  
> to infer types of variables. If the proposal is merely to save me  
> entering the type of the variable, then quite apart from the type  
> system difficulties being discussed, this saves nothing when you're  
> using an IDE.
>
> It takes two keystrokes in eclipse to assign an expression to a  
> local variable, and you get a choice of each type up the hierarchy.  
> I'm sure you can do the same in the other IDEs. Given the  
> documentary benefit of having the type name presented to you in the  
> code, and the fact that the auto proposal would seem to me to  
> encourage coding against implementation types I don't see any win  
> here, and personally would probably continue to use real type names  
> in variable declarations. (I'm aware that people's opinions on both  
> of these points differ, these aren't the main point of my post.)
>
> On the other hand, if we can use intersection types with auto/final/ 
> whatever then this genuinely adds something new to the language,  
> that is not/cannot be done by the IDE. As a comparison, as I  
> understand it, this is the main benefit given by the var construct  
> in C#, especially in combination with LINQ.
>
> Joe
>
> 2009/5/26 Reinier Zwitserloot <reinier at zwitserloot.com>
> Compared to such antics, the rules for 'final' are much, much  
> simpler: The type of the variable is the type of the RHS, unless the  
> RHS is itself an intersection type, in which case for now we can  
> just say such a construct isn't legal, and maybe later add support  
> for intersection types for variables; such a change would be  
> entirely backwards and migration compatible.
>