Documentation and error messages for synthesized `_${n}` selectors on case classes

[gsps]

The new behavior in synthesizing selectors _1, _2, etc. to a case classes' fields caught me by surprise, especially since the error messages may turn out to be quite useless:

trait EdgeLike[T] {
  def _1: T
  def _2: T
}

case class LabeledEdge[T, U](_1: T, label: U, _2: T) extends EdgeLike[T]

leads to

-- [E007] Type Mismatch Error: try/CaseClassSelectors.scala:6:51 ---------------
6 |case class LabeledEdge[T, U](_1: T, label: U, _2: T) extends EdgeLike[T]
  |                                                   ^
  |                                       found:    U(LabeledEdge.this.label)
  |                                       required: T
  |                                       
-- [E119] Duplicate Symbol Error: try/CaseClassSelectors.scala:6:46 ------------
6 |case class LabeledEdge[T, U](_1: T, label: U, _2: T) extends EdgeLike[T]
  |                                              ^
  |value _2 in class LabeledEdge is already defined as def _2: => T at line 6.

Retrospectively, I probably also ran into a very annoying interaction of this and implicits: I was expecting an implicit class with members _1 and _2 to be found, but instead got the new members on the non-wrapped class.

At a minimum, we should document the new synthesis behavior on case classes.

[Blaisorblade]

Since it took me a while to remember: Scala 2 generates no such accessors (arguably, a wart), Dotty does.

It seems we should define a semantics for _${i}-named case class fields — possibly, reject them with a specific error message in Scala 3 mode and warn about them in Scala 2 mode. The desugaring is in Desugar.classDef, around caseClassMeths. BTW, caseClassMeths ignores scala 2 mode altogether, which seems an oversight.

[smarter]

It seems we should define a semantics for _${i}-named case class fields — possibly, reject them with a specific error message

We used to do that but that broke too much code. Instead we allow them when they're defined in the correct order (_1 is the name of the first field, _2 is the name of the second field, ...). The issue here is that we don't provide any helpful error when they're not defined in the correct order.

[Blaisorblade]

Thanks, I'll take that as the needed spec for Scala 3 mode, we still need something for Scala2.