Skip to content

Under CC, subtyping between a type variable and its impure upper bound is rejected #19076

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Linyxus opened this issue Nov 25, 2023 · 1 comment · May be fixed by #23206
Open

Under CC, subtyping between a type variable and its impure upper bound is rejected #19076

Linyxus opened this issue Nov 25, 2023 · 1 comment · May be fixed by #23206
Assignees
Labels
area:experimental:cc Capture checking related cc-experiment Intended to be merged with cc-experiment branch on origin itype:bug

Comments

@Linyxus
Copy link
Contributor

Linyxus commented Nov 25, 2023

Compiler version

main

Minimized code

import language.experimental.captureChecking
trait IO

def foo[X <: IO^](x: X): IO^ = x

Output

-- [E007] Type Mismatch Error: issues/cc-typeapp.scala:4:31 ------------------------------------------------------------------------------------------------------------------------------------------------------------
4 |def foo[X <: IO^](x: X): IO^ = x
  |                               ^
  |                               Found:    (x : X)
  |                               Required: IO^
  |
  | longer explanation available when compiling with `-explain`

Expectation

It should work.

@Linyxus Linyxus added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label cc-experiment Intended to be merged with cc-experiment branch on origin and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Nov 25, 2023
@Linyxus Linyxus self-assigned this Nov 25, 2023
@Gedochao Gedochao added the area:experimental:cc Capture checking related label Jan 18, 2024
@Linyxus
Copy link
Contributor Author

Linyxus commented Feb 29, 2024

@noti0na1 and I looked into this issue and it seems to be an outcome of separating type comparison and box adaptation. What happened here:

  • In box adaptation, we see LHS is X and RHS is IO^, both unboxed, so no adaptation happened.
  • In type comparer, we widen X to box IO^ and the RHS is IO^, so the subtyping between them is rejected due to the mismatch in the box status.

In theory box adaptation and subtyping are entangled, and it seems that the entanglement does offer us more expressiveness when the adaptation and the subtyping comparison need to be interleaved, like the case here.

There are two possible solutions:

  • Widening the type parameter on LHS until we see a concrete type. But this is tricky when unions and intersections come into play. And essentially this is attempting to mimic part of the logic in type comparison.
  • Refactor box adaptation into type comparison. This solves the problem in the root. But it potentially complicates the type comparer, and states in capture checker need to be accessible from the type comparer (like the Envs that store captured variables).

We don't really know what action should be taken in this case. What do you think? /cc @odersky

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:experimental:cc Capture checking related cc-experiment Intended to be merged with cc-experiment branch on origin itype:bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants