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

Feature Request: full support for generic classes/types in custom value printing #740

Open
morgen-peschke opened this issue Feb 7, 2024 · 0 comments

Comments

@morgen-peschke
Copy link

morgen-peschke commented Feb 7, 2024

The current mechanisms for customizing value printing does not fully support generic classes, as can be seen in the example from the documentation, which does not compile without warnings:

import munit.{FunSuite, Printer}

class CustomListOfCharPrinterTest extends FunSuite {
  override val printer = Printer.apply {
    case l: List[Char] => l.mkString
  }

  test("lists of chars") {
    val expected = List('h', 'e', 'l', 'l', 'o')
    val actual = List('h', 'e', 'l', 'l', '0')
    assertEquals(actual, expected)
  }
}

Output:

sbt:root> Test/compile
[info] compiling 1 Scala source to /Users/morgen/scratch/target/scala-2.13/test-classes ...
[error] /Users/morgen/scratch/src/test/scala/com/morgen/CustomListOfCharPrinterTest.scala:7:13: non-variable type argument Char in type pattern List[Char] (the underlying of List[Char]) is unchecked since it is eliminated by erasure
[error]     case l: List[Char] => l.mkString
[error]             ^
[error] No warnings can be incurred under -Werror.
[error] two errors found
[error] (Test / compileIncremental) Compilation failed
[error] Total time: 3 s, completed Feb 7, 2024, 6:59:49 PM
sbt:root>

This is likely because the current way the pretty printer works is via reflection. AFAIK the only way around this would be to switch to an implementation based on implicits.

Pros:

  • Could compile without warnings
  • Easy to hook into existing mechanisms like cats.Show
  • Can fall back to calling printer/munitPrint for compatibility with existing customization mechanisms.

Cons:

  • Requires significant changes to the API surface
  • Harder to debug if it's not printing the way that's expected
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant