THANK YOU SO MUCH

re: testing, what you might do is add a partest case to run (i.e. test/files/run/<test-name>.scala and test/files/run/<test-name>.check). The test can define a case class like one of the examples you gave in the PR description, and then print an instance of it. e.g.

case-class-toString.scala`:

object Test extends App {
  case class A(i: Int, s: String)
  println(A(1, foo))
}

case-class-toString.check:

A(i=1, s=hello)

Sorry, but I have to voice a negative vote on this one. This is going to break so much code, if only existing tests, that the convenience is never going to be worth it.

If only we had done that while we could, like in 2.9.x or something. But now is too late.

it might be worth opening a thread on contributors before doing more work, to see what the consensus of others is (if there is one)

Mentioned this at https://contributors.scala-lang.org/t/case-class-tostring-new-behavior-proposal-with-implementation/2056

@sjrd Is the argument against ("is going to break so much code") from the standpoint that people out there parse the string output of case classes? Or is there some other consideration?

Is the argument against ("is going to break so much code") from the standpoint that people out there parse the string output of case classes? Or is there some other consideration?

Unit tests often make assertions like assertEquals("List(CaseClass(32))", list.toString. It is a bit lazy, but sometimes its the most concise way of writing a test.

Similarly, some applications might be including CaseClass#toString in messages that they display to their users. Any change here, without an escape hatch, could ripple into unexpected problems.

Perhaps an annotation could be used to configure the generated toString. It isn't that much more concise than override def toString = FancyToString(this), though.

Great if this were opt-in (and ideally per-field, but that might be too much to ask). You could add a trait FancyToString { final def toString: String = ... } to avoid having to throw this work away in the face of people's legitimate objections to a blanket change.

(Which I agree with: I often feel the lack of "named args" in the built in toString, but I wouldn't want to have them in every case any more than I would want to use named args in every method invocation.)

Please continue the discussion about the idea behind this change in https://contributors.scala-lang.org/t/case-class-tostring-new-behavior-proposal-with-implementation/2056, rather than here.

Redacted, moved comment to contributors discussion https://contributors.scala-lang.org/t/case-class-tostring-new-behavior-proposal-with-implementation/2056/29?u=olafurpg

I reallllllly wish I could be in favor of this but with sadness and regret I lean towards @sjrd's position :-/

at least, I don't think we can simply merge this for 2.13 as-is :-/ :-/ :-/

perhaps we can continue to explore whether there's a way this could happen in stages. e.g. the "opt-back" proposal is interesting.

@SethTisue do you think that there's any potential for a ClassicToString style mixin? Something like...

import scala.runtime.ScalaRunTime._toString
trait ClassicToString { this: Product => 
  def toString = _toString(this)
}
case class A(i: Int, b: Int) extends ClassicToString

?

Thank you for proposing and discussing this! I understand this is desirable, but we can't change this behavior anymore, at least not by default. I hope we can all rally behind #6972 to get that into M5 (I'm +1 on that one). I hope that will provide a good building block for a nicer, opt-in, case class toString, which is clearly on many wishlists.