Optional boolean doesn't satisfy switch exhaustivity with literal case statements

[jpsim]

Describe the bug

When switching over an optional boolean with true and false literals, an error diagnostic is produced claiming that the switch statement is not exhaustive. This is inconsistent with other pattern matchable value types which unwraps the optional to perform a match.

Steps To Reproduce

func over(bool: Bool?) {
  switch bool { // Switch must be exhaustive
  case true:
    break
  case false:
    break
  case .none:
    break
  }
}

Expected behavior

No diagnostic should be produced, as the switch is exhaustive. For example if we redefine a Bool-like enum, the exhaustivity checker works correctly and no diagnostic is produced:

enum BoolEnum {
  case truthy
  case falsy
}

func over(boolEnum: BoolEnum?) {
  switch boolEnum {
  case .truthy:
    break
  case .falsy:
    break
  case .none:
    break
  }
}

Screenshots

Environment (please fill out the following information)

• OS: [e.g. macOS 11.0] macOS 13.0 (22A380)
• Xcode Version/Tag/Branch: Xcode 14.0 (14A309), Swift version 5.7 (swiftlang-5.7.0.127.4 clang-1400.0.29.50)

[CodaFi]

Unfortunately, we cannot consider this to be exhaustive because these are expression patterns that are subject to the ~= operator.

  switch bool { // Switch must be exhaustive
  case true:
    break
  case false:
    break
  case .none:
    break
  }

https://github.com/apple/swift/blob/main/stdlib/public/core/Policy.swift#L324

[CodaFi]

To make these patterns again, you can spell them as case true?: or case .some(true):

[jpsim]

Ok thanks for clarifying that, @CodaFi.

However, even if the general ~= expression case can't be fully solved, it seems like it should be possible (and beneficial) to handle Bool? specifically here?

[CodaFi]

True, we could add an extremely special case that detected an arbitrary number of optional injections applied to a ~= with a literal at the root. And we'd have to make sure it was the ~= in the stdlib specifically.

[ashuthe1]

hey! I want to work on this issue, but I am new to open source .
could you please guide me.

[AnthonyLatsis]

Hi Ashutosh, have you read the README?

[swiftlysingh]

Hey @ashuthe1 are you working on this?

@AnthonyLatsis I have read the docs, build the swift project on my machine, kind of understand the problem statement. Would love to get started with this!

[AnthonyLatsis]

Hello @swiftlysingh, you are welcome to give it a go but I wouldn’t say this issue is a great candidate for a very first contribution if you’re new to this sort of stuff. Not without some prior reading and research, at least.

[AnthonyLatsis]

Unfortunately, we cannot consider this to be exhaustive because these are expression patterns that are subject to the ~= operator.

@CodaFi I believe this is an actual bug, because without the optional the boolean literals would have resolved to Bool patterns. Given a true/false switch over a Bool is considered exhaustive, I think this should too.

[swiftlysingh]

I am in for some research, if it is required. I come across this issue while going through the "good first issue" label.

Which issue would you recommend for getting started? @AnthonyLatsis

[AnthonyLatsis]

We have a list of external resources with some great introductory blog posts and talks. The AST section is generally a good place to start with in terms of implementation.

I come across this issue while going through the "good first issue" label.

This is a special GitHub label, so we cannot customize the name. We use it to mark onboarding issues in general — both the ones that are best suited for first-time contributions, and the ones that warrant basic familiarity with a certain area.

Which issue would you recommend for getting started?

Something like this, this or this. This one should be alright with a bit of reading.

[swiftlysingh]

Looking into this issue. Sorry for the delayed response. Will be reading up on blogs and talks from the external resources as well!

[Vivek09Chahal]

enum BoolEnum {
case truthy
case falsy
case none // case of none
}

func over(boolEnum: BoolEnum?) {
switch boolEnum {
case .truthy:
break
case .falsy:
break
case .none:
break
}
}

we can add a case of none and than try it, might resolve this issue.

[doriandevtech]

Hey ! Is anyone currently looking at this issue ? 👀

If not, I'd to try resolving it 🤩