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
pattern matcher allows wrong number of subpatterns in extractor #6675
Comments
Imported From: https://issues.scala-lang.org/browse/SI-6675?orig=1 |
@paulp said: |
@paulp said: |
@paulp said: |
@paulp said: def unapplyArity: Int for those cases where you want them to differ. But the worst scenario is the present one, where the pattern matcher is "flexible" in regards to the arity - maybe it's 1, maybe it's 3, let's see what works. We should be looking for more type safety in the matcher, not less. |
@rkuhn said: |
@paulp said:
That's a pretty emphatic way to say you expect Tuple1, but the parentheses are discarded and you are happily handed a 3tuple. (Typing out Tuple1(b) correctly fails.) |
@Blaisorblade said: How's this fix supposed to make its way into 2.10.1, since it will break source code which 2.10 had started accepting? Sure people will start using this, and I'd argue you can't change the pattern matcher behavior in a point release, even more so now that we even have binary compatibility. IOW, source compatibility is to me stricter than binary compatibility (and yes, we need to figure this out once and for all). Unlike for libraries, it's a bit hard to argue then break their code arguing that this is "unspecified behavior": in general, not reading Scaladocs is not excusable, while ScalaReference is often (and in this case) more complex to read. The specification didn't change between 2.9 and 2.10, but the behavior did; and by looking at the text, it's not a prime example of pedagogical clarity in this matter, especially if you're used to the behavior pre-2.10. |
@paulp said: |
@rkuhn said: |
@retronym said: |
@Blaisorblade said: Finally, legalese-speaking, the current spec indeed supports Adriaan; but pedagogically speaking, this behavior is allowed so implicitly that I suspect who wrote the text did not mean to allow this behavior, or simply did a very poor job at explaining it, so that even Adriaan was confused. |
@paulp said: |
@Blaisorblade said: |
@retronym said: |
@retronym said: |
@paulp said: |
@retronym said:
|
@paulp said: |
@retronym said: |
@paulp said: |
@paulp said: |
@adriaanm said: |
@rkuhn said: |
@adriaanm said: |
`case extractor(extracted) => extracted` yields ``` Warning:(68, 16) class ValueExtractor expects 2 patterns to hold (String, String) but crushing into 2-tuple to fit single pattern (scala/bug#6675) ``` See * scala/bug#6675 * scala/bug#6111
In addition to matching the contents of a tuple returned by
def unapply
, scala 2.10 also allows a single pattern matching the tuple itself. This is a regression from 2.9 in terms of pattern verification.This is problematic because there is no warning (except in certain lucky cases) if argument patterns are forgotten, resulting in a case statement which will never match, e.g.
case X(x: SomeTrait)
.The text was updated successfully, but these errors were encountered: