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

[Ruslan Shevchenko]

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

 Economically, value of code owning is mostly cost of reading than
cost of writing. I. e. I think 'IDE can do this' is not very valuable
argument.

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

 I guess, that main value of 'auto' proposal is not think about exact
verbose implementation type at all, during writing and reading code.
Pattern 'use interface names for variable types' exists (not fully, but I
guess in many) on absence of auto keyword. Most local variables are short
living and have no assignments from different implementations of
interface.
And if we need exactly detail type  - we still can write one.


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