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

[Reinier Zwitserloot]

On May 16, 2009, at 06:27, Lawrence Kesteloot wrote:

> Reinier Zwitserloot wrote:
>> 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
>
> Nobody is forcing me to use it, but unfortunately no one can stop my
> co-workers from using it either.

Then you missed the point of the post. Unless you think forcing your  
coworkers to write:

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

is a good idea.

> You might argue that I already don't
> explicitly know the type of, say, the "getX().getY()" sub-expression,
> but it's only used in passing and I don't really care. What I need to
> know is, "What can I do with params?"

Why do you not care here:

a.getB().doC();

but you do care here:

final z = a.getB();
z.doC();
z.doD();

That's arbitrary. You can't just hand-wave and say its 'only used in  
passing and I don't care' in one situation but in the other situation  
it all of a sudden becomes crucial.

The -exact- -same- conditions would apply to variables created with  
"final name = expr;"

I grok the basic idea of "I want to know the type of my expression". I  
agree with you. This is nice to know. But you're going to have to come  
to terms with the fact that java does not now and will not ever give  
you this stuff in the raw source file in all situations. That's not  
feasible.

I repeat: Why is re-using without using chaining so special that you  
want to force explicit typing on everybody?

>
>
> Reading code is hard enough without forcing this extra work on the
> reader.

If I understand you correctly, I can use your argument to state that  
this:

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

is more readable than this:

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

which I'm fairly sure nobody agrees with.

I posit instead that eliding type information from expressions that  
aren't mutable does not neccessarily lead to making code harder to  
read, and in many cases can help make it easier to read by not  
foisting irrelevant information onto your eyeballs.

> And writing the type isn't much of a burden for the author,
> since he already knows it.

The amount of boilerplate elimination is staggering. Compared to most  
of the other proposals on this list, it wins. I hope it's self-evident  
to the members of this mailing list that java programmers routinely do  
NOT make their local variables final just because of the minor burden  
of typing it out. Therefore, please stop acting as if this change is  
just trying to save people some typing. That's not at all what's at  
stake. Instead, there are 2 pretty major improvements involved:

  1. More local finals, which makes everybody happy, and
  2. Less noise by expanding the existing mechanism of offering the  
programmer to, at their discretion, elide explicit type information.

Saving some characters is just gravy.

> I don't particularly buy the argument that "the IDE can just tell
> you." I'm not sure we want to turn Java into a language that's only
> usable in a small set of editing environments.

Straw man. I said: If you care about that sort of stuff, you *NEED*  
*TO* *USE* an IDE. You're acting as if this change all of a sudden  
changes the situation, which is false. Expressions in java aren't  
always manifestly typed. Period. If you want to chase down such types  
easily, you need an editor. 'final name = expr;' does not change this  
at all.

  --Reinier Zwitserloot