Skip to content
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

Expressiveness limitation when mapping a list of capabilities #20204

Open
Linyxus opened this issue Apr 16, 2024 · 2 comments · May be fixed by #20250
Open

Expressiveness limitation when mapping a list of capabilities #20204

Linyxus opened this issue Apr 16, 2024 · 2 comments · May be fixed by #20250
Labels
area:experimental:cc Capture checking related itype:bug

Comments

@Linyxus
Copy link
Contributor

Linyxus commented Apr 16, 2024

Compiler version

main

Minimized code

import language.experimental.captureChecking

trait Source[+T]:
  def poll(): T

trait List[+T]:
  def foreach[R](op: T => R): Unit

def foo[T](sources: List[Source[T]^]): Unit =
  sources.foreach(_.poll())

Output

-- Error: issues/mapsource.scala:10:10 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
10 |  sources.foreach(_.poll())
   |  ^^^^^^^^^^^^^^^
   |  Reach capability cap and universal capability cap cannot both
   |  appear in the type [R](op: box Source[T]^{sources*} => R): Unit of this expression

Expectation

It should compile.

@Linyxus Linyxus added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label area:experimental:cc Capture checking related and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Apr 16, 2024
@Linyxus
Copy link
Contributor Author

Linyxus commented Apr 16, 2024

Right now when something does not pass the checkReachCapsIsolated check we issue an error. Maybe we could widen all reach capabilities in that type to cap (so the refining is reverted) and proceed? /cc @odersky

@odersky
Copy link
Contributor

odersky commented Apr 16, 2024

Yes, I think that's worth trying. It would be nice if we issued an error message that explains what went on if the thus widened type does not conform to the expected type.

@Linyxus Linyxus linked a pull request Apr 23, 2024 that will close this issue
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 itype:bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants