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

[Reinier Zwitserloot]

replies inline.

  --Reinier Zwitserloot



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
>


Wahuh?

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