Imported From: https://issues.scala-lang.org/browse/SI-5898?orig=1
Reporter: Aaron Novstrup (anovstrup)
See #140, #900

Aaron Novstrup (anovstrup) said:
Related discussion:
Is MatchError becoming Scala's NullPointerException?
type matching in for comprehensions

Aaron Novstrup (anovstrup) said:
I've looked at this more closely and realized that a major premise of my proposal is flawed: namely, that many extractors could guarantee a Some return value. Because of our old friend null, this is not possible. For case classes, for example, the generated unapply method returns None when passed a null.

Some alternative solutions:

• Type check these definitions more strictly, and require additional syntax (e.g. the case keyword) to obtain the (current) less strict type checking
• Annotate unapply methods such as Tuple2.unapply to indicate that they are guaranteed to return a Some as long as the argument is non-null, and directly invoke unapply (as in the original proposal) when the annotation is present. If the rhs is null, throw an appropriate exception (preferably not MatchError)

@LilyLambda said:
This is not a type safety violation. If it fails at runtime with a MatchError then there's no safety problem. As for detecting necessarily failing patterns at compile time ... well, that's a major area of research in static analysis. The compiler does not even attempt, in general, to detect failing matches in constructions (like val assignments) where only one pattern is given. I think this is very much an improvement and not a bug.

Aaron Novstrup (anovstrup) said (edited on Jun 20, 2011 3:24:44 AM UTC):
@yuvi I understand that there a different notions of type safety, but in the context of a statically typed language such as Java or Scala it is pretty common to view unexpected runtime type errors as type safety violations.

Semantics aside (I'm more concerned with the issue than with the title), the problem with these constructs is that there is no clue in the syntax that unchecked matching is going on and that a runtime error may arise. Furthermore, there is no reason that unchecked matching should be going on (in the very common, specific cases considered here, such as tuples and case classes).

Having a match error occur in what appears to be a perfectly safe assignment is similar to having something like a MissingMethodError occur on a method call when it is known at compile time that the method is not a member of the target object's type.

@SethTisue said:
"val (a,b) = 1" in fact fails to compile.

"val (a,b) = 1: Any" is pretty strange code. The ": Any" tells the compiler, "forget
everything you know about this expression, just treat it as Any". Then when compilation
succeeds, it's a little funny to complain that the compiler didn't use its knowledge of
what "1" is, when you explicitly told it not to.

Why I would be using practically useless, vague types like Any and Product anyway...?

I'm not critiquing your overall goals here, I'm just saying you need more compelling
use cases if you want to build support for changes in this area.

Aaron Novstrup (anovstrup) said (edited on Jun 20, 2011 9:27:18 PM UTC):
@seth I agree that these examples aren't compelling -- my intent was to give examples that would exhibit the behavior with the least amount of extraneous cruft to wade through (i.e. simplicity over realism). My related comments on the mailing list make the case a bit more clearly:

https://groups.google.com/d/topic/scala-user/21IbHRhgxQU/discussion

"The real danger, of course, is that the right-hand side need not be
typed explicitly. The type may be inferred locally, or it may be the
return type of a method, etc. A refactoring could easily lead to
runtime failures."

The complaint is not that the compiler does not use its knowledge of what "1" is, but rather that it doesn't use its knowledge of what Tuple2 is. Any unintended widening of the static type on the right-hand side could lead to runtime failure. Here's a more realistic example (although it fails the simplicity test):

class Character(name: String)
case class Player(name: String, age: Int, gender: Gender) extends Character(name)
case class NPC(name: String, species: Species, language: Lang) extends Character(name)

// Originally, getCharacter returns a Player.  Later, it's modified 
// to return a Character. After the change, the following line of 
// code will still compile but may fail at runtime.  
val Player(_, a, g) = getCharacter("Dingus")

The original developer intended his code as shorthand for

val c = getCharacter("Dingus")
val a = c.age
val g = c.gender

which would fail to compile after the change in getCharacter.

Aaron Novstrup (anovstrup) said (edited on Jun 20, 2011 9:31:50 PM UTC):
Another (more) realistic example:

// original
List(1 -> "a", 2 -> "b") map { p => val (a,b) = p; a + " -> " + b }

// changed: oops!
List(1 -> "a", 2 -> "b", 3) map { p => val (a,b) = p; a + " -> " + b }

@som-snytt is scala/scala#7526 something you plan to pick up again, or is this up for grabs?

@SethTisue that one was resubmitted and merged. I don't remember, but I don't think it's enough to close the ticket.

oh, scala/scala#7687

@SethTisue sorry to make work for you. Unless you need work? Probably you don't need work.

it beats watching TV