VERSION 2: Re: Proposal: Type inference for variable definition/initialization using the 'auto' keyword.
reinier at zwitserloot.com
Mon May 25 17:12:07 PDT 2009
Why not drop the 'auto' keyword entirely? Using just 'final' has
plenty of advantages:
1. No need to add a new keyword, which, lets face it, project coin is -
NEVER- going to allow, ever. 'module' is okay because it's context
sensitive, but auto cannot be. The following code:
auto x = 10;
is technically parsable right now, in java 1.6: It's like 'String x =
10;' except instead of 'String' we have a type named 'auto', which is
technically legal even though its against convention by having a type
with a lowercase first letter.
2. No confusion around the following code:
auto list = new ArrayList();
list = new LinkedList(); //fail: LinkedList is not an ArrayList!
NB: It is infeasible to automagically detect that 'list' should be
typed as just a List, and its quite a stretch for java to start
considering ALL assignments and type the variable name with the
intersection type(s). Compared to such antics, the rules for 'final'
are much, much simpler: The type of the variable is the type of the
RHS, unless the RHS is itself an intersection type, in which case for
now we can just say such a construct isn't legal, and maybe later add
support for intersection types for variables; such a change would be
entirely backwards and migration compatible.
3. Less impactful; Assigning into a variable whose type is inferred
from an expression is a much bigger deal than inferring the type of an
unchanging reference. In the latter case, the link between the
inferred type of a variable and its contents is obvious: It's the type
of the content, period. In the former case, the type of a variable can
be different from the content if you've reassigned, which leads to
NB: Howard, making 'auto' optional is a very bad idea, IMO. It
wouldn't be consistent:
"a = 4;"
can now mean either: assign the result of expression '4' to the
existing variable named 'a', and make sure the type of the expression
is compatible with the type of 'a', OR: Create a new variable named
'a', and infer the type off of the expression '4', then assign the
result of that expression to it.
I -really- doubt java is the type of language to roll with creating
variables on the fly when assigning to them, python-style. I rate the
odds of that going into coin as 'when pigs fly'. Thus, we are stuck
with inferring 'auto' only if there are OTHER keywords involved, but
other than 'final', that never happens for method locals. Thus, you
must be talking about type inference for fields, which is far too big
a change for coin; consider:
1. Fields can be accessed outside of scope, which means the type
information on the variable is much more important. Typing a list as
'ArrayList' instead of a 'List' is a bad thing for a field, but only a
very minor style incursion for a final method local, and yet outlawing
'auto foo = new ArrayList();' seems arbitrary and wrong.
2. Even for a private field, where access is restricted to reflection,
the scope of the field is much larger than for method locals, which
considerably adds to the damage done by not being explicit about the
type. For method locals, the places where the variable is used is
usually fairly easy to spot (and if not, you should be splitting up
your methods!). For fields, this is obviously not the case. You lose
perspective of your inferred type.
On May 25, 2009, at 22:31, Tim Lebedkov wrote:
> Hello Howard,
> (Jeremy - FYI)
> I have thought about it also. It would be useful to make "auto"
> It was just not in the original proposal. And it would help (I'm not
> quite sure whether it is enough) with the "final" proposal from Jeremy
> Making "auto" optional would also allow code like
> static a = "clouds";
> private b = 44;
> I'm not quite sure yet whether I can change my proposal and about the
> implications and acceptance (and possible danger to the whole
> proposal) of this change.
> On Mon, May 25, 2009 at 1:00 AM, Howard Lovatt
> <howard.lovatt at iee.org> wrote:
>> The example:
>> final auto list = new ArrayList<String>();
>> seems strange, why not:
>> final list = new ArrayList<String>();
>> After all you are trying to reduce verbosity and making final
>> declarations the same length as variable ones will encourage people
>> use final more, which is a good thing. The use of just final has been
>> proposed by many people for Java already, it won't break code. Also
>> this final only construct is consistent with other languages e.g.
>> Scala, JavaFX, etc. that use def and var (final and auto
>> -- Howard.
More information about the coin-dev