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

[Tim Lebedkov]

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

AUTHOR(S): Tim Lebedkov

OVERVIEW

Provide a two sentence or shorter description of these five aspects of
the feature:

FEATURE SUMMARY: Should be suitable as a summary in a language tutorial.

This proposal addresses the addition of type inference for
variable definitions to the Java programming language using the 'auto'
keyword instead of specific type name.

For example, consider the following assignment statement:

Map<String, List<String>> anagrams = new HashMap<String, List<String>>();

This is rather lengthy, so it can be replaced with this:

auto anagrams = new HashMap<String, List<String>>();

and anagrams is automatically typed as HashMap<String, List<String>>

MAJOR ADVANTAGE: What makes the proposal a favorable change?

Generics have had a tremendously positive impact on type safety in the
Java programming language. They  have made it possible to provide
static guarantees about the type of instances used by other classes,
preventing entire classes of runtime errors from occurring. However,
generics have added complexity to Java, making the code far more
verbose and occasionally difficult to read. Although solving this
problem is well outside the scope of this proposal, a limited form of
type inference would remove unnecessary redundancy from the language.
Even without generics it seems unnecessary to duplicate type names for
simple variable definitions/assignments like:

Integer a = new Integer(1023);

MAJOR BENEFIT: Why is the platform better if the proposal is adopted?

Less code and no duplication has a positive impact on many things:
- faster typing/faster code changes
- easier code changing without IDE assistance
- code versioning diffs are more clear

MAJOR DISADVANTAGE: There is always a cost.

- it could be harder to read the code.
- auto will be a keyword and may break some old code

ALTERNATIVES: Can the benefits and advantages be had some way without
a language change?

no

EXAMPLES

SIMPLE EXAMPLE: Show the simplest possible program utilizing the new feature.

1. simple assignment

Map<String, List<String>> a = new HashMap<String, List<String>>();

becomes

auto a = new HashMap<String, List<String>>();

2. auto in for

List<String> list = ...
for (auto s: list)
    ...
	
3. auto for a final variable

final ArrayList<String> list = new ArrayList<String>();

becomes

final auto list = new ArrayList<String>();

4. class field definition

class A {
    String a = "";
}

becomes

class A {
    auto a = "";
}

ADVANCED EXAMPLE: Show advanced usage(s) of the feature.

auto i = 5 + 3;  // same as "int i = 5 + 3"
auto i = 5 + 3L;  // same as "long i = 5 + 3L"
for (auto entry : (new HashMap<Integer, String>>).entrySet()) { }

DETAILS

SPECIFICATION: Describe how the proposal affects the grammar, type
system, and meaning of expressions and statements in the Java
Programming Language as well as any other known impacts.

Informally, the specification adds syntax to replace the type definition
in variable definitions with assignments by 'auto'. The type of the variable
is automatically determined.

COMPILATION: How would the feature be compiled to class files? Show
how the simple and advanced examples would be compiled. Compilation
can be expressed as at least one of a desugaring to existing source
constructs and a translation down to bytecode. If a new bytecode is
used or the semantics of an existing bytecode are changed, describe
those changes, including how they impact verification. Also discuss
any new class file attributes that are introduced. Note that there are
many downstream tools that consume class files and that they may to be
updated to support the proposal!

The resulting bytecode would be identical to bytecode generated by the
same code with the types inferred.

TESTING: How can the feature be tested?

The proposed construct can be tested by writing a number of statements
that construct instances using
inferred types. These instances can then be assigned to variables and
fields of specific types, and passed to
methods that expect specific types. These tests should compile and run
as expected:
auto set = new SortedSet<String>();
set.add("A");
set.add("B");
set.add("C");
// verify that set contains "A", "B", "C".

LIBRARY SUPPORT: Are any supporting libraries needed for the feature?

No library support is required, although libraries can be rewritten to
take advantage of the new feature.

REFLECTIVE APIS: Do any of the various and sundry reflection APIs need
to be updated? This list of reflective APIs includes but is not
limited to core reflection (java.lang.Class and java.lang.reflect.*),
javax.lang.model.*, the doclet API, and JPDA.

No reflective APIs need to be changed.

OTHER CHANGES: Do any other parts of the platform need be updated too?
Possibilities include but are not limited to JNI, serialization, and
output of the javadoc tool.

No other parts of the platform need to be updated.

MIGRATION: Sketch how a code base could be converted, manually or
automatically, to use the new feature.

Libraries can be rewritten to take advantage of this feature, but it
is not imperative that they do so.

COMPATIBILITY

This change is backwards incompatible on the source code level.

BREAKING CHANGES: Are any previously valid programs now invalid? If
so, list one.

All programs that use auto as a name for an identifier would become invalid.

EXISTING PROGRAMS: How do source and class files of earlier platform
versions interact with the feature? Can any new overloadings occur?
Can any new overriding occur?

The feature is completely transparent to the class files. Class files
do not contain
any information about the variables declared using 'auto'.

REFERENCES

[1] Thanks to Jeremy Manson (his proposal served as a template for this one)
http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000009.html
[2] Jaako Jarvi and Bjarne Stroustrup. Decltype and auto (revision 3).
Paper N1607,
JTC1-SC22/WG21, February 17 2004. Online: http://www.open-std.org/jtc1/
sc22/wg21/docs/papers/2004/n1607.pdf; same as ANSI NCITS/J16 04-0047.
[3] James Gosling, Bill Joy, Guy Steele, and Gilad Bracha. The Java
Language Specification, 3rd Edition.
Addison Wesley, 2004.


EXISTING BUGS: Please include a list of any existing Sun bug ids
related to this proposal.
6242254, 4983159, 6368076

URL FOR PROTOTYPE (optional):
none