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

[Joe Kearney]

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.