Confusing error message with missing implicit doesn't show bounds of constrained type variables

[dlwh]

Forgive is this is a dupe or a known change. I read the spec more carefully this time and watched @smarter's talk but didn't see anything that was directly addressing this. I think that Scala 3 is more aggressive at pinning primitive types than it used to be

Compiler version

3.0.0-RC2

Minimized code

trait Op[T1, T2, +R] {
  def apply(t1: T1, t2: T2): R
}

object Op {
  implicit val compInt: Op[Int, Int, Int] = new Op[Int, Int, Int] {
    def apply(x: Int, y: Int) = scala.math.min(x, y)
  }
}

object Foo {
  def foo(x: Double) = x + 1.0
  def min[T, U, V](x: T, y: U)(implicit op: Op[T, U, V]): V = op(x, y)
  def minInt(x: Int, y: Int)(implicit op: Op[Int, Int, Int]): Int = op(x, y)
  def minR[R](x: Int, y: Int)(implicit op: Op[Int, Int, R]): R = op(x, y)
  min(3, 4) // works in both
  foo(min(3, 4)) // works in Scala 2, not in 3
  foo(minInt(3, 4)) // works in both
  foo(minR(3, 4)) // works in Scala 2, not in 3
}

Output

17 |  foo(min(3, 4))
   |               ^
   |no implicit argument of type Op[Int, Int, V] was found for parameter op of method min in object Foo
19 |  foo(minR(3, 4))
   |                ^
   |no implicit argument of type Op[Int, Int, R] was found for parameter op of method minR in object Foo

Expectation

I'd prefer the Scala 2 behavior very much, though I can probably work around it with enough implicit magic, but at the very least, I'd prefer that the error message was a bit more specific: telling the user that V == Double or something. I was confused for a long time if there was some other change to implicit scope I didn't understand (the Op impls were elsewhere in my actual code)

[smarter]

This doesn't look specific to primitives, when we type min(3, 4) inside of foo(min(3, 4)), we know the result type has to be a subtype of Double and therefore V <: Double, and so Op[Int, Int, Int] doesn't fit, I guess Scala 2 doesn't propagate the constraint from the result type correctly, and this happens to do the correct thing because you're relying on the implicit conversion from Int to Double to kick in later, but it's inevtable that better type inference breaks usages of implicit conversions (hence why we'd like to get rid of them as much as possible: https://contributors.scala-lang.org/t/proposed-changes-and-restrictions-for-implicit-conversions/4923).

but at the very least, I'd prefer that the error message was a bit more specific: telling the user that V == Double or something

I agree, the error message should mention that V <: Double

[dlwh]

Makes sense and I agree implicit conversions are evil. Int->Double etc promotion are getting caught in the dragnet then?

…

On Mon, Apr 26, 2021 at 1:46 PM Guillaume Martres ***@***.***> wrote: This doesn't look specific to primitives, when we type min(3, 4) inside of foo(min(3, 4)), we know the result type has to be a subtype of Double and therefore V <: Double, and so Op[Int, Int, Int] doesn't fit, I guess Scala 2 doesn't propagate the constraint from the result type correctly, and this happens to do the correct thing because you're relying on the implicit conversion from Int to Double to kick in later, but it's inevtable type inference breaks usages of implicit conversions (hence why we'd like to get rid of them as much as possible: https://contributors.scala-lang.org/t/proposed-changes-and-restrictions-for-implicit-conversions/4923 ). but at the very least, I'd prefer that the error message was a bit more specific: telling the user that V == Double or something I agree, the error message should mention that V <: Double — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#12232 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACLIKEYVUDG2BKLFRFWDDTKXGJVANCNFSM43TUURLA> .

[smarter]

Well nothing has been decided regarding the future of implicit conversions but I don't think we'll ever get rid of widening numeric conversions like Int to Double.

[dlwh]

for anyone stumbling on this in the future. You can get the old Scala 2 behavior with something like

  implicit def castReturnTypeOp1[T1, T2, R, R2](implicit op: Op[T1, T2, R], conversion: R=>R2): Op[T1, T2, R2] = {
    (t1: T1, t2: T2) => conversion(op(t1, t2))
  }

(I don't totally understand why it's R=>R2 and not Conversion[R, R2], but the latter doesn't work)

Buyer beware etc etc. I'll probably restrict to a set of scalar types in practice rather than allowing any implicit conversion.