VERSION 2: Re: Proposal: Type inference for variable definition/initialization using the 'auto' keyword.
reinier at zwitserloot.com
Tue May 26 15:26:54 PDT 2009
On May 27, 2009, at 00:10, Tim Lebedkov wrote:
> I assume you know about the main disadvantage, but I'll write it one
> more time:
> You cannot define a mutable variable using "final".
That's an advantage, actually, because mutating a variable whose type
is auto inferenced by its first assignment is problematic. e.g:
auto foo = new ArrayList();
foo = new LinkedList(); //this fails, and that is a clear failure of
the compiler to Do What I Mean.
> I hope we can have a new keyword :-)
We can't. You can ask Joe if you aren't willing to take my word for
it, but I'll eat my right shoe if a new global keyword (vs. a context
sensitive one like 'module'), especially something as common as
'auto', which I'm sure exists as many a variable name already, is
deemed acceptable for Project Coin. Seriously. Pigs flying, hell
freezing over, and other such statements aren't hyperbole here.
> compiler should probably generate 2 errors for the second line here:
> final list = new ArrayList();
> list = new LinkedList(); //fail: LinkedList is not an ArrayList!
> 1st error: you cannot assign a new value to a final variable
> 2nd error: incompatible types
> It seems "final" instead of "auto" has no real advantage here
I don't get what you're saying. In the 'final' case, the behaviour is
no different compared to what happens now: Trying to reassign a final
variable gets you a 'you can't reassign final variables' error. Great
- that's what final is for. I would have expected that problem.
However, in the incompatible types case, we now have an error where
previously, before the auto proposal, there wouldn't have been an
error, because the author would have instinctively used List instead
of ArrayList. I would NOT have expected this error. In fact, in other
languages you wouldn't even get that error, because the type of the
LHS is inferred from *all* RHS expression types assigned to it. I
already mentioned why this strategy is not feasible for java.
> If "auto" is more "impactful", then in a very small degree.
I backed up my argument. You can't just say "it isn't" and wave a
magic wand. You have to take my arguments and prove why they are
either wrong, or trivial.
> you'll need either
> auto a = 4;
> final a = 4;
> a = 4 is an assignment
Yes. Which is inconsistent, and means that 'auto' does need to exist,
so what's the point of doing this in the first place? If you could
make the need for a keyword go away altogether, you'd be on to
something very important (given that you just can't add a keyword for
Project Coin - not gonna happen). So, what's the goal? Saving 5
characters of typing? If your main aim in this proposal is to shave
off a bunch of 5 character sequences, I think you're doing this for
all the wrong reasons. The advantages of eliding the LHS type is not
just saving characters (though, for certain types, you can save quite
a few of them; a lot more than 5!) - it's not having to bother looking
up a type, adding an import statement in certain cases, and having
code migrate automatically even if the RHS expression changes type
because you're still in the pre-API-lockdown phase of development.
> the usage of instance fields outside of the declaring class are rare.
> Additionally we have at least 3 sources for the type information:
Irrelevant; it's not about figuring out what the type is - it's that
the type will likely be wrong, because it's needlessly specific
(ArrayList vs. List).
More information about the coin-dev