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

[SR-5088] Integer switch not seen as exhaustive #47664

Open
CharlesJS opened this issue Jun 4, 2017 · 4 comments
Open

[SR-5088] Integer switch not seen as exhaustive #47664

CharlesJS opened this issue Jun 4, 2017 · 4 comments
Assignees
Labels
compiler The Swift compiler in itself improvement

Comments

@CharlesJS
Copy link

Previous ID SR-5088
Radar rdar://61080252
Original Reporter @CharlesJS
Type Improvement
Status Reopened
Resolution
Environment

Apple Swift version 3.1 (swiftlang-802.0.53 clang-802.0.42)

Additional Detail from JIRA
Votes 1
Component/s Compiler
Labels Improvement
Assignee @CodaFi
Priority Medium

md5: c7872aebfaa1b675af0c385589a85dfd

is duplicated by:

  • SR-7081 "Switch must be exhaustive" when it actually is

relates to:

  • SR-766 Switch doesn't need to cover negative Int cases

Issue Description:

Switching over an integer type seems to get flagged as not being exhaustive, even if it is. For example, the following switch will generate an error for not being exhaustive:

func doSomething(byte: UInt8) {
    switch byte {
    case UInt8.min...UInt8.max:
        print("How could this not be exhaustive?")
    }
}
@CodaFi
Copy link
Member

CodaFi commented Jun 5, 2017

This is an area of Switch statement analysis I really want to be able to cover at some point. I just have no idea how to efficiently represent this for the different kinds of integers Swift supports. It seems like we need some kind of bounded Index Set type for this.

@belkadan
Copy link
Contributor

belkadan commented Jun 5, 2017

Quoting @jckarter from an earlier bug:

Unfortunately, integer operations like '...' and '<' are just plain functions to Swift, so it'd be difficult to do this kind of analysis. Even with special case understanding of integer intervals, I think there are still cases in the full generality of pattern matching for which exhaustiveness matching would be undecidable. We may eventually be able to handle some cases, but there will always be special cases involved in doing so.

We're unlikely to special-case this given that matching the entire integer space is not a very common thing to do.

@jckarter
Copy link
Member

jckarter commented Jun 5, 2017

It's maybe more likely with smaller types like Int8/Int16, or with enums that are `Comparable`.

@CodaFi
Copy link
Member

CodaFi commented Apr 9, 2020

I don't know why we closed this. It's a worthy enhancement to exhaustiveness checking if done in an (albeit) limited way.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler The Swift compiler in itself improvement
Projects
None yet
Development

No branches or pull requests

4 participants