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

[Reinier Zwitserloot]

Actually, almost all java programmers routinely do not specify the  
type of expressions. Easily 95%+ of all java code.

Example:

System.out.println(new StringBuilder().append("Hello,  
").append("World!").toString());

This rookie coder clearly needs to be a taught a lesson - that is not  
readable at all because he's elided 4 types from this code! It should  
be:

System.out.println((String)((StringBuilder)((StringBuilder)new  
StringBuilder.append("Hello, ")).append("World!")).toString());

Much more readable.

</sarcasm>

Folks, expressions are left without manifest typing ALL THE TIME. The  
argument that this is 'unjavalike' is frankly ridiculous. There's a  
fine argument for *mutable* variables to be forcibly manifest typed,  
to make sure you don't run into silly surprises, such as:

auto x = new ArrayList<String>();
if ( someFoo ) {
    x = Collections.emptyList();
}

generating a compiler error (because Collections.emptyList returns a  
List, whereas the type of x got inferred to ArrayList. You can't  
assign a list to an arraylist). This is an annoying puzzleresque  
problem that should be avoided if at all possible, which is why I  
totally agree that auto is not a good idea without a way to solve this  
problem.

But that problem only applies to mutables. Therefore:

final foo = "Hello, ";

is perfectly java-esque, and has no such problems because you can't re- 
assign foo in the first place. It should also provide a very soft  
incentive for java programmers everywhere to learn to mark local stuff  
as final if they aren't going to change it anyway - and to not reuse  
variable names just to save on typing. The boundary between the  
meaning of the expression and the meaning of the variable is already  
blurred here; the variable IS the expression; that's what final means.

There's a point to the argument that explicit types help make things  
clear, but you just *can't* expand that argument to FORCING it onto  
the programmer. There's a reason java allows you to chain method calls  
and put expressions in the position where you're supposed to put a  
method parameter. Typing every expression is patently insane. No  
programming language has ever gone there, and I bet no language  ever  
will.

It should be optional. And it will be, if you add the 'final varName =  
expression;' syntax to java. Nobody is forcing you to use it - adding  
the type (final Type varName = expressionCompatibleWithType;) won't be  
going away, of course.


Perhaps someone can enlighten me why using an expression more than  
once requires you to explicitly type it, UNLESS you reuse the  
expression by way of method chaining (such as StringBuilder's append).  
I accept the argument that this isn't worth changing because its not  
enough value for the impact (I'd disagree, but I could be persuaded),  
but the argument that this is somehow the java way or sensible for  
readability reasons - I don't buy that for a second, that makes no  
sense at all. That kind of readability is best enabled by smart  
editors that will tell you the type of any expression anywhere by way  
of e.g. tooltips.

  --Reinier Zwitserloot



On May 16, 2009, at 01:15, Rémi Forax wrote:

> Mark Thornton a écrit :
>>> You're right. These two classes are not statistically significant,  
>>> but:
>>> - number of lines where "auto" can be used is always >= the number  
>>> of
>>> lines where "diamond" can be used
>>>
>>>
>>>
>> Only if you don't follow the common policy of using an interface  
>> type on
>> the left hand side. With that policy 'auto' is unusable.
>>
>
> The common policy is stupid because you should only use interfaces  
> when
> needed.
> When you write a code you talk to the guys that will read it.
> So If you put an interface, you say something like, here the code is  
> not
> obvious
> because more that one implementations may be used.
> Only code your needs, never more.
>
>>> OK. I didn't know that Java was designed to explicitly declare the
>>> type of variables on the left hand side,
>>> but even if it was, it's worth changing.
>>>
>>>
>> It allows it and it is a common policy that many have deliberately
>> chosen to use and recommend.
>>
>> Mark Thornton
>>
>>
> Rémi
>