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

🐛 Fix MatchError bug with sealed trait -> open trait refactor #109

Merged
merged 1 commit into from
Oct 21, 2022

Conversation

jeffmay
Copy link
Owner

@jeffmay jeffmay commented Oct 21, 2022

Description

Fixes a bug with a MatchError being thrown when using the Fact or DerivedFact extractors on custom Fact subclasses.

Type of change

  • Bug fix (non-breaking change which fixes an issue)

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • Any dependent changes have been merged and published in downstream modules
  • I have checked my code and corrected any misspellings

@jeffmay jeffmay force-pushed the jeff/fix-match-error branch from bd1a3c8 to 8c0465c Compare October 21, 2022 03:58
Copy link
Collaborator

@paul-a-kennedy-rally paul-a-kennedy-rally left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

def unapply[A](fact: TypedFact[A]): Some[(FactType[A], A)] = fact match {
case SourceFactOfType(typeInfo, value) => Some((typeInfo, value))
case DerivedFactOfType(typeInfo, value, _) => Some((typeInfo, value))
}
def unapply[A](fact: TypedFact[A]): Some[(FactType[A], A)] = Some((fact.typeInfo, fact.value))
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know why this wasn't a compiler error... TypeFact was not sealed...

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... it looks like the Scala compiler only checks for exhaustivity of sealed traits / classes. Removing the sealed qualifier broke the match statement AND simultaneously prevented the compiler from flagging it as an error... that kinda sucks. I feel like the compiler should always assume in-exhaustivity for any unsealed (i.e. open) type without a case _.

@jeffmay jeffmay merged commit 7006e5c into v1 Oct 21, 2022
@jeffmay jeffmay deleted the jeff/fix-match-error branch October 21, 2022 18:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants