Proposal: Type inference for variable definition/initialization using the 'auto' keyword.
reinier at zwitserloot.com
Fri May 15 21:45:27 PDT 2009
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:
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:
but you do care here:
final z = a.getB();
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
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
If I understand you correctly, I can use your argument to state that
is more readable than this:
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
More information about the coin-dev