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

conditional given with recursive type can't find extension method #8311

Closed
bishabosha opened this issue Feb 13, 2020 · 1 comment
Closed

Comments

@bishabosha
Copy link
Member

bishabosha commented Feb 13, 2020

Minimized code

package example

trait Show[O]:
  def (o: O).show: String

class Box[A]
class Foo

given Show[Foo] = _.toString
given [A](using Show[A]): Show[Box[A]] = _.toString

def run(s: Box[Box[Foo]]): Unit =
  summon[Show[Box[Box[Foo]]]].show(s) // it can find the given here
  println(s"step: ${s.show}") // tries to call show on Show[Box[Foo]]

Compilation output

-- [E008] Member Not Found Error: givens.scala:14:22 
 14 |  println(s"step: ${s.show}")
    |                    ^^^^^^
    |    value show is not a member of example.Box[example.Box[example.Foo]].
    |    An extension method was tried, but could not be fully constructed:
    |
    |        example.givens$package.given_Show_Box[example.Foo](
    |          example.givens$package.given_Show_Foo
    |        ).show(s)
@odersky
Copy link
Contributor

odersky commented Feb 16, 2020

This one does not work either:

    val r: String = box.show(s)

The problem is that we are asking to find an implicit given information that is far apart. Indeed we need to construct the full implicit so that afterwards we can run show on it, and have it applied be to the right argument. Currently the argument's type is not propagated. This is probably a prudent thing to do since forcing argument types like that can cause problems by itself. For instance, one could fail to compute a parameter type, or miss another implicit conversion.

I fear we have reached the limit of what bidirectional type inference can do here. I see no way to improve this that might not potentially break other things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants