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

[alex]

Hi Tim,
a little bit late comment...

what if 

Map<String, List<String>> anagrams();

compiled as

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

?



In more general way for a class C

C c( constructor-args );

would be equivalent to

C c = new C( constructor-args );

@lex

ps: C++ trick ;-)


On Saturday 28 March 2009 09:35:46 Tim Lebedkov wrote:
> 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