Details
-
Bug
-
Resolution: Fixed
-
P3
-
None
-
Verified
Description
Given an inference bound like
z <: Foo<t>
Where 'z' is a capture var, it should be the case that 't' depends on the resolution of 'z'. (This is unusual -- usually the dependency goes the other direction, with 'z' depending on 't'.)
Currently, no dependency between the two is specified.
Fortunately, incorporation passes most useful information from 'z' to 't' anyway, but not always:
interface PonyList<T extends Pony> extends List<T> {}
PonyList<z> = capture(PonyList<? extends x>)
z <: Bar<t>
z <: Foo<t>
Where 'z' is a capture var, it should be the case that 't' depends on the resolution of 'z'. (This is unusual -- usually the dependency goes the other direction, with 'z' depending on 't'.)
Currently, no dependency between the two is specified.
Fortunately, incorporation passes most useful information from 'z' to 't' anyway, but not always:
interface PonyList<T extends Pony> extends List<T> {}
PonyList<z> = capture(PonyList<? extends x>)
z <: Bar<t>
Attachments
Issue Links
- relates to
-
JDK-8054721 18.4: Clean up resolution of capture ivars
- Open
-
JDK-8028800 Lambda Spec: Support capture when a nested invocation returns an inference variable
- Closed