Skip to content
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

Guard causes pattern matching to not warn of non-exhaustivity #7631

Closed
scabug opened this issue Jul 3, 2013 · 7 comments
Closed

Guard causes pattern matching to not warn of non-exhaustivity #7631

scabug opened this issue Jul 3, 2013 · 7 comments
Assignees
Milestone

Comments

@scabug
Copy link

@scabug scabug commented Jul 3, 2013

in Scala 2.10.2, this warns me about a non-exhaustive pattern match...

sealed trait Test
case class TestA() extends Test
case class TestB() extends Test

object Tester {
  val input : Test = TestA()
  val x = input match {
    case TestA() => 2
  }
}

// But this does not:

object Tester {
  val input : Test = TestA()
  val num = 3
  val x = input match {
    case TestA() if num == 3 => 2
  }
}

The compiler should be able to determine that a guard clause cannot increase exhaustivity. While I can accept the decision not to make the exhaustivity search be pessimistic (which could result in some false warnings, if something always evaluates to true for some reason), it should at least be able to determine that the case of TestB() is not handled.

@scabug
Copy link
Author

@scabug scabug commented Jul 3, 2013

Imported From: https://issues.scala-lang.org/browse/SI-7631?orig=1
Reporter: Scott Danzig (sdanzig)
Affected Versions: 2.10.2
Duplicates #5365

@scabug
Copy link
Author

@scabug scabug commented Jul 3, 2013

@paulp said:
It seems reasonable that we should always perform exhaustiveness checking and simply ignore guards so we can report types which are definitely not covered. It's not ideal that there's no indication that exhaustiveness checking is not being performed if you add a guard somewhere; I don't think there's anything to be done about that though, as it would be super noisy to do so.

Actually like a lot of things, the useful warning would be issued at the point when you change the code, not as a consequence of the code when considered in isolation. ("Warning: the guard you just added disabled exhaustiveness checking.") That of course is not something which can be done in the compiler given present abilities.

@scabug
Copy link
Author

@scabug scabug commented Jul 3, 2013

Scott Danzig (sdanzig) said (edited on Jul 3, 2013 2:40:16 PM UTC):
My thoughts are that the compiler could be made "pessimistic" about exhaustivity with guards given a compiler option to enable this.

I agree that the currently impractical warning at the time of the change would be most helpful, but it'd easily be missed unless there was a separate log for "change-related notifications" along with the diff.

@scabug
Copy link
Author

@scabug scabug commented Jul 3, 2013

@paulp said:
When I wrote that I was imagining immediate feedback, but when you put it that way it occurs to me that we could obtain some useful change-oriented messages by post-processing the repository.

The major category where I dream of being told that something changed is variable shadowing, e.g. when you change something called "sym" to another name, only to see a "sym" from an enclosing scope step in as a substitute, and everything compiles and you don't know that you failed to change a reference to "sym" to the new name.

@scabug
Copy link
Author

@scabug scabug commented Jul 3, 2013

Scott Danzig (sdanzig) said:
Perhaps similar notifications could be made for inherited methods/classes taking over as well. I see a lot of potential. I'm not finding other languages' compilers that implement this type of checking.

@scabug
Copy link
Author

@scabug scabug commented Sep 29, 2015

Richard Bradley (richard.bradley) said:
(This looks like a duplicate of #5365 (closed). I agree that the compiler should not treat guard clauses as "always true" for the purposes of exhaustivity checking. This causes lots of problems. See my detailed comments on #5365.)

@scabug
Copy link
Author

@scabug scabug commented Jan 29, 2016

@retronym said:
Merging with #5365.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants