intersection type compatibility

[Dan Smith]

On Dec 7, 2013, at 8:29 AM, Stephan Herrmann <stephan.herrmann at berlin.de> wrote:

>> Giving us bounds:
>> { t <: Object, exp <: ArrayList<String>, exp <: List<t> }
>> 
>> It would be nice if we could then infer something about t...  But we don't, and so resolution finds t := Object, and then there's no solution for exp.
> 
> I see I had a bug here. Just to double check: when we create fresh type variables
> for t and exp (say z-t and z-exp) where z-exp has upper bounds ArrayList<String>
> and List<z-t>: Is it a proper application of the well-formedness constraint in 18.4
> to skip this solution candidate and continue?

Yes, this is exactly the kind of thing that is meant to be detected by that check.

I see that the "else" branch of the well-formedness condition doesn't actually appear in the paragraph.  I'll have to fix that.  If the fresh type variable is not well-formed, resolution must simply give up.

>> Well, it's a spec bug, but one that's already been identified:
>> https://bugs.openjdk.java.net/browse/JDK-8028813
> 
> Thanks for the reference.
> BTW, are there other open bugs against spec part G
> that I should know about?

>> We're planning to come up with an extra incorporation rule that will handle cases like this.
> 
> Will you post on this list when a draft of the new rule is available?

Later this week, watch for a summary of all Public Review feedback and changes, along with an updated spec.

—Dan