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

[Tim Lebedkov]

---------- Forwarded message ----------
From: Tim Lebedkov <tim.lebedkov at googlemail.com>
Date: 2009/3/31
Subject: Re: Proposal: Type inference for variable
definition/initialization using the 'auto' keyword.
To: ÏòÑÅ <fyaoxy at gmail.com>


Hello,

yes, this syntax is possible, but I don't like it because of an
implicit variable definition (without the "auto" keyword).

Regards
Tim

2009/3/30 ÏòÑÅ <fyaoxy at gmail.com>:
> Hi,
> Seems should have no problem
> String sample="1"
> for(simple: list){
>  //at here the coder should reference the simple var
> //2 case: simple type same as sample, or not same
> //case 1, not same, the simple is new variable, not problem
> //case 1,  same,
> //in the loop, or after loop, the coder reference sample, but indeed
> simple handed, sample not.
> //so maybe bugs, but the case not problem too in unit test sight
> }
>
> 2009/3/30 Tim Lebedkov <tim.lebedkov at googlemail.com>:
>> Hello,
>>
>> as far as I understand, you propose to drop the "auto" keyword from
>> the statements.
>> This would lead to many bugs if you mistype an identifier.
>> Example:
>>
>> String sample = "1";
>>
>> for (simple: list) { // it should be *sample*
>>    //
>> }
>>
>> use sample here...
>>
>> --Tim
>>
>> 2009/3/28 ÏòÑÅ <fyaoxy at gmail.com>:
>>> 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
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Ö¾´
>>> ÏòÑÅ
>>>
>>
>
>
>
> --
> Ö¾´
> ÏòÑÅ
>