Case class allows case-field named "productArity", which creates havoc with Product

[jraty]

% scala -version
Scala code runner version 3.1.1 -- Copyright 2002-2022, LAMP/EPFL

Case class allows case-field with name productArity without any warning/error. This silently breaks functionality of Product.
It is not obvious that case class extends Product and field with productArity should not be used.
Suggestion: make productArity illegal as a case-field or at least warning.

Example:

object Bug {

  case class Problem(productArity : Int)

  def main(args : Array[String]) : Unit = {
    val cc = Problem(42)
    println("wtf?: "+cc.productArity) //42
  } 
}

[som-snytt]

Same behavior in Scala 2.

Possible messaging: productArity, productElement, and productElementName should be overridden together. Or consider also overriding productElement, etc.

Is it a coincidence that jraty is nearly an anagram of arity?

[odersky]

The expansion of a case class is documented. If you do override productArity you need to know what you are doing. I do not think we should try to enforce a universal rule that you are not allowed to write it.

I do not think this is a good first issue, since this requires a well thought out decision what to do.

Maybe something like what @som-snytt proposes, but I am not sure.

Possible messaging: productArity, productElement, and productElementName should be overridden together. Or consider also overriding productElement, etc.

Also, the fact that Scala 2 has lived with this for 15+ years shows it's not urgent we fix this.

[jraty]

On 13.04.2022 11:17, odersky wrote: The expansion of a case class is documented. If you do override productArity you need to know what you are doing. I do not think we should try to enforce a universal rule that you are not allowed to write it.

The point was: accidentally overriding productArity, without any kind of indication that it is happening. (I admit, it is rare that any experienced programmer falls for this and chances are slim that you happen to use exactly that name and correct type). At least documents: https://docs.scala-lang.org/overviews/scala-book/case-classes.html https://docs.scala-lang.org/scala3/book/domain-modeling-tools.html do not mention in any way that case class and product have anything to do with each other. It seems clear (to the newbie at least) that you can use any names as fields of case class, and in case you happen to use something like "toString" or "productPrefix", compiler will issue error (because of the lack of 'override'). Method productArity happens to be abstract and therefore overridable without noticing (and you are not using "extends" to realize that you should be aware of it). If you do it on purporse, for example if "override" would be required, then it is no longer accidental.

Also, the fact that Scala 2 has lived with this for 15+ years shows it's not urgent we fix this.

Well, it took also for me 15 years to realize this, so neither it is urgent for me and work-around is quite trivial - however, it is a possible source for silent bug that might result in very confusing behaviour in some other part of the code. When teaching about one of the pinnacles of Scala, the Case Class, you must remember to add "...don't override productArity accidentally". <sarcasm>Sounds pythonic...?</sarcasm>

[odersky]

There are a number of definitions that are overridden by a case class only if the case class does not define a same-named member itself. That's the documented behavior, and there are cases where that is done intentionally. If we prevent you from doing that by issuing an error we break that behavior and code that relies on it.

So the best you could hope for would be a warning if things obviously make no sense. But in many cases where we have added such a warning, we have come to regret it afterwards since perfectly good code would then trigger the warning. These things are extremely subtle, and it is much easier make things worse than improve them in my experience.