-
Notifications
You must be signed in to change notification settings - Fork 11
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
Investigate why creating a Monad[[X] => A => X]
instance causes ambiguous extension method errors
#2
Comments
Monad[[X] => (A => X)]
instance causes ambiguous extension method errorsMonad[[X] => A => X]
instance causes ambiguous extension method errors
Is this because of List’s apply method? |
Yeah, I assume it's because List extends Seq extends PartialFunction extends Function1. |
Aha! That makes sense, though I don't know how we should go about fixing here. I had hoped the more specific implied instance would have been selected. |
Contextual clues help, but only a little:
|
With 3.0.0-RC3:
|
@mpilquist There's a good chance this is the same issue as scala/scala3#12126 |
scala/scala3#12126 is now fixed, but this issue remains, after uncommenting src/main/scala/leopards/instances/function1.scala and setting scalaVersion to [root@test]> test:compile
[error] -- [E007] Type Mismatch Error: /home/smarter/opt/spotted-leopards/src/test/scala/leopards/FirstExample.scala:7:21 --------------------------------------------------------------------------------------------------
[error] 7 | assertEquals(List(1, 2) *> List(3, 4), List(3, 4, 3, 4))
[error] | ^^^^^^^^^^
[error] | Found: List[Int]
[error] | Required: ?{ *> : ? }
[error] | Note that implicit extension methods cannot be applied because they are ambiguous;
[error] | both given instance given_Monad_Function in package leopards and object given_Monad_List_Traverse_List in package leopards provide an extension method `*>` on List[Int]
[error] one error found So a minimization would still be useful here I think. |
When we compare polymorphic methods for specificity, we replace their type parameters by type variables constrained in the current context (see isAsSpecific), but for extension methods in polymorphic givens, the comparison was done with a constraint set that does not include the type parameters of the givens, this lead to ambiguity errors as experienced in typelevel/spotted-leopards#2. We fix this by ensuring the TyperState we use for the comparison contains any additional constraint specific to the TyperState of either alternative. This required generalizing TyperState#mergeConstraintWith to handle `this` not being committable (because in that case `this` does not need to take ownership of the type variables owned by `that`, therefore `that` itself is allowed to be committable).
I have a fix I think: scala/scala3#13509 |
Fixed as of |
Fixed by #14 |
When we compare polymorphic methods for specificity, we replace their type parameters by type variables constrained in the current context (see isAsSpecific), but for extension methods in polymorphic givens, the comparison was done with a constraint set that does not include the type parameters of the givens, this lead to ambiguity errors as experienced in typelevel/spotted-leopards#2. We fix this by ensuring the TyperState we use for the comparison contains any additional constraint specific to the TyperState of either alternative. This required generalizing TyperState#mergeConstraintWith to handle `this` not being committable (because in that case `this` does not need to take ownership of the type variables owned by `that`, therefore `that` itself is allowed to be committable).
With
function1.scala
uncommented, expressions likeList(1, 2).void
result in errors like:The text was updated successfully, but these errors were encountered: