-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Problems inferring correct type for extension methods #11413
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
Comments
To add some more information and context here. I can make the code work by adding the following implicit class conversion. It seems like this is a bit messy and would cause confusion to the users and I can't explain why I need it other than to help the type.
It makes me wonder though if my issue is a typer bug, if I am needing a fix like this one... Kinda-Curried Type Parameters https://tpolecat.github.io/2015/07/30/infer.html It seems to me that the very same code in Scala 2 style (which also needs the implicit Ops conversion class) should translate to Scala 3 and not need it. Anyway, hope this helps bring clarity to the issue. |
It would be really helpful for us if you could reduce your code example to the minimal amount of code needed to reproduce the issue: it doesn't have to make sense, just to demonstrate that something isn't inferred when it could. |
Sounds good. I have removed a significant amount of code. |
Just an update, it definitely isn't related to the "kinda-curried" type parameters link above. So I'm still not really sure if I should be expecting this to type check or not. It seems to me that it should be able to construct the extension method without the ambiguity it is seeing. |
Here pure10.flatMap(a => Transformer(Option(a + 1))) expands to transformerMonad.flatMap(pure10)(a => Transformer(Option(a + 1))) and at this point compiler is confused while at the point of evaluating
|
Thanks for the help, so it seems like this isn't a bug and can be closed. |
Uh oh!
There was an error while loading. Please reload this page.
Compiler version
3.0.0-RC1
Minimized code
Output
Expectation
Code should compile with no ambiguity
The text was updated successfully, but these errors were encountered: