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

Type inference does not work on methods using dependent types and parameters with default value #7234

Open
scabug opened this issue Mar 8, 2013 · 8 comments

Comments

@scabug
Copy link

@scabug scabug commented Mar 8, 2013

Here is a minimal test case that shows the problem:

trait Main {

  trait A {
    type B
  }

  trait C {
    def c(a: A, x: Int = 0)(b: a.B)
  }

  def c: C

  def ok(a: A)(b: a.B) = c.c(a, 42)(b)

  def fail(a: A)(b: a.B) = c.c(a)(b)

}

If I remove the x parameter default value, or explicitly fill its value, it works fine.
But compiling the above code produces the following error:

[error] /Volumes/Home/workspace/scala-dependent-types/src/main/scala/Main.scala:15: type mismatch;
[error]  found   : b.type (with underlying type a.B)
[error]  required: x$1.B
[error]   def fail(a: A)(b: a.B) = c.c(a)(b)
@scabug
Copy link
Author

@scabug scabug commented Mar 8, 2013

Imported From: https://issues.scala-lang.org/browse/SI-7234?orig=1
Reporter: Julien Richard-Foy (julienrf)
Affected Versions: 2.10.1-RC3, 2.11.0-M1
See #7238

@scabug
Copy link
Author

@scabug scabug commented Mar 8, 2013

Julien Richard-Foy (julienrf) said (edited on Mar 8, 2013 10:15:46 PM UTC):
Note that if the c method is a top-level method rather than a method of the trait C, it compiles fine:

trait Main {

  trait A {
    type B
  }

  def c(a: A, x: Int = 0)(b: a.B)

  def ok(a: A)(b: a.B) = c(a, 42)(b)

  def ok2(a: A)(b: a.B) = c(a)(b)

}

@scabug
Copy link
Author

@scabug scabug commented Mar 9, 2013

@retronym said:
Thanks for the clear bug report.

Working on a fix: https://github.com/retronym/scala/compare/ticket/7234

Still a few subtle interactions to deal with.

Here's a related crasher:

trait Main {
  trait A {
    type B
  }
  trait C {
    def c(a: A, x: Int = 0)(bs: a.B*)
    def d(a: A, x: Int = 0)(b: a.B)
  }
  def c: C
  def fail3(a: A)(b: a.B) = c.c(a)(Seq[A#B](b): _*) // should fail, crashes with .setInfo(null)
}

@scabug
Copy link
Author

@scabug scabug commented Mar 9, 2013

@retronym said (edited on Mar 9, 2013 4:08:04 PM UTC):
I've opened another ticket for that crasher, #7238.

@scabug
Copy link
Author

@scabug scabug commented Mar 9, 2013

@scabug
Copy link
Author

@scabug scabug commented Mar 11, 2013

Julien Richard-Foy (julienrf) said:
Great, thanks for your reactivity.

@scabug
Copy link
Author

@scabug scabug commented May 27, 2013

@retronym said:
Unfortunately we had to revert this due to #7516.

Right now, I don't see a straight forward way to deliver this fix without breaking that again.

@SethTisue
Copy link
Member

@SethTisue SethTisue commented Jun 27, 2017

this appears to be another manifestation of the same problem:

scala> trait T; class C[T2 <: T](val t: T2, b: Boolean = true, n: Int = 0)
defined trait T
defined class C

scala> val t = new T { }
t: T = $anon$1@f2a1813

scala> new C[t.type](t)
res0: C[<refinement>.type] = C@7645f03e

scala> new C[t.type](t, n = 1)
<console>:15: error: type mismatch;
 found   : T
 required: <refinement>.type
Error occurred in an application involving default arguments.
       new C[t.type](t, n = 1)
                     ^

@retronym remarks:

We don't have a transform: foo(bar, baz) to val x$1 = bar; val x$2 = baz; foo(x$1, x$2)
without messing up the types in some circumstances. If we let the types of the synthetics be inferred (by typechecking the ValDef with an empty tpt), we get unwanted widening. If we manually assign the return type to be the same as type of the expression on the LHS, we ran into some bad interaction in macro land.

@scala scala deleted a comment from scabug Jun 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants