Prevent Pattern Match Exhaustivity Warning for `transparent`

[eaplatanios]

Hi, I believe that pattern match exhaustivity warnings should not be emitted for top-level pattern match statements in transparent methods, given that the pattern match is checked and expanded at compile-time anyway.

I noticed these warnings are emitted when matching over a sealed trait/class in a transparent method body.

[Blaisorblade]

A transparent method can be defined in library A and used in library B; certain bugs in A will only be visible while compiling B. So there's still a point in exhaustivity warnings.

So, can you point to any downside to these warnings? You can always add a fallback using ???.
The only issue I see is if you want a transparent method to fail if called on some cases — we can probably want a variant of ??? that triggers a compile error. Example:

// Peano naturals as in other examples, omitted
transparent def pred(n: Nat) = n match {
  case S(m) => m
// we want to fail on pred(Z)! So either omit the case or make this explicit
  case Z => compileError("Calling pred(Z) is illegal")
}
transparent def compileError(msg: String): Nothing =
  ... // XXX figure out how to implement this, or provide it ourselves

[eaplatanios]

I see your point. That makes sense. Is there a nice way currently to implement compileError? As a side note, I think that having this compileError functionality would be great because it also allows to produce nice and interpretable errors (which is not so much the case currently with implicits in Scala).

[LPTK]

In scalac, you can have scala.annotation.compileTimeOnly on local definitions, which could be used here to say that a case should never end up compiling -- that is, if Dotty respected the annotation (currently it apparently does not).

transparent def pred(n: Nat) = n match {
  case S(m) => m
  case Z =>
    @compileTimeOnly("n cannot be Z") val res = ???
    res
}

I imagine that it could also rely on constant folding of strings to compose the message at compile-time, since the annotation is checked only after type-checking and macro/transparent expansion occur.

[Blaisorblade]

(which is not so much the case currently with implicits in Scala).

That should be addressed by @implicitNotFound (not sure Dotty implements it yet but we should). And @compileTimeOnly is indeed designed for this goal, tho it honestly seems more roundabout.

Is there a nice way currently to implement compileError? As a side note, I think that having this compileError functionality would be great because it also allows to produce nice and interpretable errors (which is not so much the case currently with implicits in Scala).

Sorry for the ambiguity, I did mean "I don't know but we should have it one way or the other".

[eaplatanios]

@LPTK That annotation could be useful if the message can be treated as an error message that the compiler shows when it encounters it during transparent methods expansion.

@Blaisorblade The @implicitNotFound annotation is good, but to me it feels more natural to be able to throw error messages at compile-time through the top-level pattern match on transparent implicit methods. It reads as if it was imperative which is great, and it also allows to potentially throw different error messages based on what pattern can be matched, which can help produce even more informative errors for common misuses of a particular API.

[LPTK]

@eaplatanios

That annotation could be useful if the message can be treated as an error message that the compiler shows when it encounters it during transparent methods expansion

I'm not sure I understand. When properly implemented (as in scalac), compileTimeOnly does create an error message shown when the annotated thing is encountered – which could be as the result of transparent method expansion

[eaplatanios]

@LPTK Sorry what I meant to say that if that's what this annotation does then that's great! I was just not familiar with it. :)

[soronpo]

I imagine that it could also rely on constant folding of strings to compose the message at compile-time, since the annotation is checked only after type-checking and macro/transparent expansion occur.

Is it possible to create a transparent string interpolation?

[Blaisorblade]

This topic came out today on Gitter, and there's a WIP implementation in #4964 (currently in 2710e2b).