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

[Joe Kearney]

Again, I realise that documentation of the type vs length and other
considerations is a contentious issue. For the case of types with lots of
parameters, however, it might be interesting to note that these will be
covered nicely by the other typing proposals:
final Map<String, List<Set<Integer>>> foo = new HashMap<>();

You're right that the IDE won't help shorten long non-paramatrised type
names if you don't want to see that in the code at all. My personal opinion
is that "auto" is of limited value if the intention is only to shorten type
names, especially in light of what the IDE can do for you. But I can see
that it solves this part of the problem for those who hold other opinions.

Thanks,
Joe

2009/5/26 Reinier Zwitserloot <reinier at zwitserloot.com>

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