@implicitNotFound string interpolator doesn't work with types

[anatoliykmetyuk]

import scala.annotation.implicitNotFound

@implicitNotFound("Not found for ${A}")
type F[A]

@implicitNotFound("Not found for ${A}")
trait G[A]

def f[T] given F[T] = ???
def g[T] given G[T] = ???

@main def Main = {
  f[String]
  g[String]
}

Out:

-- Error: ../pg/Main.scala:13:11 -----------------------------------------------
13 |  f[String]
   |           ^
   |           Not found for ${A}
-- Error: ../pg/Main.scala:14:11 -----------------------------------------------
14 |  g[String]
   |           ^
   |           Not found for String
two errors found

[anatoliykmetyuk]

We should also support this:

@implicitNotFound("Not found for ${A} and ${B}")
type F = [A] =>> [B] =>> Any

Maybe substitute placeholders if the type lambda is partially applied:

@implicitNotFound("Not found for ${A}, ${B}")
type F = [A] =>> [B] =>> (A, B)

@main def Main = {
  the[F[Int]]  // Not found for Int, <unbound>
}

[b-studios]

In the meantime the observed behavior changed. The first error is not "Not found for ${A}", but Not found for which is even more confusing.

For completeness: it also does not work on opaque types which came as a surprise to me:

import scala.annotation.implicitNotFound

object bugreport {
  @implicitNotFound("Could not find ${A}")
  opaque type F[A] = A
}

def foo = summon[bugreport.F[Int]]

[prolativ]

@b-studios am I right that @implicitNotFound (or annotations in general) should not be allowed on non-opaque types? because they're just aliases?

[b-studios]

Actually, I am not sure about this. It sounds like it would be easier to forbid them, but if I search for a type before dealising and it has an annotation, then in general it should be possible to report it for this case. I wouldn't use the annotation for the right-hand side, though.

[prolativ]

Well, currently when you have

import scala.annotation.implicitNotFound

trait Foo
type Bar = Foo @implicitNotFound("There's no Bar")
@implicitNotFound("There's no Baz") type Baz = Foo

then for summon[Baz] you get the custom message but for summon[Bar] you don't. That's quite unintuitive for me. Should these two cases be equivalent or not? Or what's wrong with right-hand side annotations then?

[julienrf]

am I right that @implicitNotFound (or annotations in general) should not be allowed on non-opaque types? because they're just aliases?

I think it makes sense to support at least abstract type members (which have not been aliased yet).

[YulawOne]

No sure about difficulty here, but I just got an example where it's really useful to have implicitNotFound on type alias:

@implicitNotFound("Cannot proof type inequality because types are equal: ${A} =:= ${B}")
type =!:=[A, B] = NotGiven[A =:= B]

def compileIfNotSameType[A, B](using A =!:= B): String = "ok"

compileIfNotSameType[String, String]
// expected compile message: Cannot proof type inequality because types are equal: String =:= String

While without it compilation message is quite cryptic about missing given. So I don't think annotation should be forbidden 🤔

[joroKr21]

Hmm, in Scala 3.3.1 it doesn't work at all for type aliases with a type parameter. It does work for simple type aliases.