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

[=?GB2312?B?z/LRxQ==?=]

Hi,
A variable declaration has 3 kind of style:
1, field: class Case1{ fieldType fieldName;}
2, local: method or si, type varName;
3, statement, for(type var...)
then do assignment,
switch(case)
1: the "fieldName" field type determinated, so assignment value must
acceptable by the field type. so the generic type argument is no need
at all.
2: split 2 child case, 2.1assign a given argument, which type
determinated, same as 1.
    2.2 new local var, Yes, the new instance and generic type argument
is just my want. in this case, the type of local variable is no need
at all.
3: same as 2.2
So I would hope this:
class Test{
  List<String> list1 = new ArrayList();
  List<String> list2;
  Test(){
      list2 = new ArrayList();
  }
  void test(List<String> list){
     list = new ArrayList();
     list2 = new ArrayList<Integer>();
     for(s: list) handleString(s);
     for(i: list2) handleInteger(i);
  }
}

What do you think?

2009/3/28 Tim Lebedkov <tim.lebedkov at googlemail.com>:
> 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
>
>



-- 
Ö¾´
ÏòÑÅ