resolving several ivars to the same capture?

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Thu Oct 23 14:53:05 UTC 2025


On 23/10/2025 12:10, Stephan Herrmann wrote:
> Am 23.10.25 um 12:45 schrieb Maurizio Cimadamore:
>> On 23/10/2025 11:25, Stephan Herrmann wrote:
>>> Doesn't 4.10.2 clearly state that type arguments should be captured 
>>> here?
>>
>> Yes, but that means that we will generate “spurious” capture 
>> variables during inference which will end up in the result. Depending 
>> on the case, this might result in failures.
>
> define "spurious"! :)
I think Dan has explored this topic in more details and might have more 
examples of when the extra captures generated during incorporation might 
lead to bad inference results. I'll leave this with him.
>
>
>> If this is indeed connected to the spec issue I mentioned above, then 
>> I’d say that it’s sad but also sort of ok for the compilers to 
>> diverge, given that a “real” fix will in reality be a lot more 
>> convoluted than just applying capture.
>
>
>
> What is the perspective for things to eventually clear up?

These issues are complex and take quite a bit of time to fix (compiler 
implememtation being the least concern) while, at the same time, they 
tend to impact a relatively low number of users. So prioritization for 
these things is always tricky. You can expect new features to keep 
cleaning up things as required. Some examples:

* local variable type inference introduced a new _upward projection_ 
routine which I suspect can be used as a basis for some of the subtyping 
woes mentioned in this thread (as an upward projection is the closest 
upper bound of a type that is free of captured type-variables)
* pattern matching is increasingly refining and polishing the story 
around cast conversions
* flexible constructor bodies required a fair deal of cleanup in the 
definitions of local class well-formedness

I believe this to be a good and pragmatic way to keep moving towards a 
place where compiler and spec are closer together, while adding 
interesting new features to the platform.

So, no, an umbrella JEP for "type system fixes" is almost certainly not 
how these issues will be addressed.

Maurizio





More information about the compiler-dev mailing list