[Checkers] Question about resolving type variables

[Mahmood Ali]

Hi Mike,

> Incidentally, whenever there is an interesting design/implementation
> question like this, let's record it somewhere. [...]
Thank you for taking a note of this.  Errr... we should be writing  
about difficulties about implementing the system and our experience  
with the Javac API also I guess.

> However, when the type is used as a generic argument, extra  
> specificity is
> no advantage.
Actually, extra specificity guarantees soundness of the type system.

> 1. Supply the context (the expected type) to inference, and if that  
> type is
> possible to achieve, then use it instead of the most specific type.   
> (This
> would make the "List<Object>" Java example type-check, too!)
This would render the system unsound.  For example, Arrays.asList()  
specification states that it 'Returns a fixed-size list backed by the  
specified array. (Changes to the returned list "write through" to the  
array.)'

Allowing this proposal would render the following code valid:
         String[] array = new String[] { "m", "n" };
         List<Object> lst = Arrays.asList(array);
         lst.set(0, new Date());  // eq. to array[0] = new Date();

A similar code could be constructed to violate the type qualifier  
rules (e.g. for array String[@Interned]).

> Problems:
> * must supply the type context.  This probably isn't a big deal.
Actually, we already use the type context to infer types not specified  
via arguments (e.g. Collections.emptyMap()).  Rather than supplying an  
context argument,  AnnotatedTypeMirror uses TreePath to get the  
assignment context.

> 2. Make the programmer supply an explicit type to override the default
> behavior.  I'm not sure whether the default behavior in this case  
> should be
> "List<String>" (for backward compatibility) or "List<@Interned  
> String>"
> (for precision).  I lean slightly toward the latter but can't  
> justify my
> intuition.
I am in favor of supporting the latter (List<@Interned String>) to  
avoid potential type errors described above.  However, it is a bit  
annoying to break backward-compatibility and may require us to explain  
our choice if we do so.

> 3. Other ideas?


I wonder if it will be possible to change the assigned to variable  
type to the appropriate type.  So for the following example:
	List<String> lst = Arrays.asList(array); // where array is of type  
String[@Interned];
	lst.set(0, new String());
lst will get the type List<@Interned String>, thus the checker would  
issue an error for the set method invocation, but not of the assignment.

Personally, I think this proposal will complicate the implementation  
very much, and makes debugging harder.

Thanks,
Mahmood