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

Exhaustive match (RFC 40) #1891

Merged
merged 1 commit into from
May 10, 2017
Merged

Exhaustive match (RFC 40) #1891

merged 1 commit into from
May 10, 2017

Conversation

jemc
Copy link
Member

@jemc jemc commented May 5, 2017

This PR implements RFC 40.

Construct a union type of all cases in the match that match on type alone,
and if this union is a supertype of the match expression type,
then the match is exhaustive so we don't need to sugar the else None.

As a result, users won't have to deal with the type system possibility of a None
result for match blocks which can easily be shown to never reach the else case.

Closes #1772.

@jemc jemc added the changelog - added Automatically add "Added" CHANGELOG entry on merge label May 5, 2017
@jemc
Copy link
Member Author

jemc commented May 6, 2017

I'm submitting this for review/merge with a couple of caveats:

  1. I wasn't able to implement exhaustive case methods (though they also weren't part of the original RFC) - see Exhaustive match does not work for case methods. #1893
  2. There are a few edge cases with tuples&unions where the compiler currently doesn't detect subtype relationships properly, and as a result, exhaustive match does not work in those cases - see Union of tuples / tuple of unions. #1892

@jemc
Copy link
Member Author

jemc commented May 6, 2017

Looks like there's a legitimate issue in the CI that needs to be fixed before merging.

Construct a union type of all cases in the match that match on type alone,
and if this union is a supertype of the match expression type,
then the match is exhaustive so we don't need to sugar the `else None`.

As a result, users won't have to deal with the type system possibility of a `None`
result for match blocks which can easily be shown to never reach the `else` case.
@jemc jemc force-pushed the feature/exhaustive-match branch from 8fe2e8d to 4820b5f Compare May 6, 2017 00:30
@jemc
Copy link
Member Author

jemc commented May 6, 2017

Alright, rebased on top of latest master and fixed the issue.

Expecting CI to pass this time.

@jemc
Copy link
Member Author

jemc commented May 6, 2017

One of the Travis builds had a blip downloading LLVM - restarted that particular build.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog - added Automatically add "Added" CHANGELOG entry on merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants