Check exhaustivity at build time for SwitchStore?

[tgrapperon]

The following refers to the branch I've published for reference. As it is not intended to be PR, I'm starting as a discussion.

I wonder why we don't use this variant of SwitchStore that would allow exhaustivity at build time? Maybe it was already discussed in some episode on pointfree.co, but I'm not really sure how far the discussion went, and I can't find the episode back.

There are of course a few issues:

• We're exposing a whole state value to switch over, and this is much more than we would probably like. I've tried to wrap it in some opaque type and implement some pattern matching overload, but without success. I'm not an expert with this though. Hopefully, if we have KeyPath for enums some day, we could rely on that to conveniently switch over¹.
• The case .route: CaseLet(state: /.route, action:… is a little awkward.
• I'm not sure that we can use switch in @ViewBuilder in SwiftUI on iOS 13. I remember some limitations with the @functionBuilder, but I'm not sure exactly which ones.

Such approach would allow to write very natural and exhaustive switches, and would also allow to deprecate, and then remove all the runtime overloads at some point.

Footnotes

1. This is maybe a possible use-case to add to a certain pitch somewhere… ↩

[mbrandonw]

Stephen and I did consider this once upon time (and even considered it again with our recent NavigationStack explorations), but ultimately decided against it for many of the same reasons you came up with.

The primary reason is that it's weird to get access to the state in the case. It may lead you to believe that the closure will be called with the freshest state anytime it changes, but that's not really the case. SwitchStores compute their bodies only when the enum tag changes, not when the state inside a case changes.

[tgrapperon]

It may lead you to believe that the closure will be called with the freshest state anytime it changes

This was exactly my concern, and why I tried to vend an opaque value to switch over. After a second thought, and as @stephencelis and yourself will likely participate in a swift-evolution pitch about built-in CasePaths, I think there's a use-case for CasePaths to inherit their Root value exhaustivity checks. For example,

enum Enum {
 case a(String)
 case b(Int)
 case c(Date)
}

let value: PartialCasePath<Enum> = \.a
switch value {
  case \.a: …
  case \.b: …
} // Error: Switch must be exhaustive

This would probably be something nice to have. If it could be subtle for general KeyPaths, it seems relatively straightforward for CasePaths.
In this situation, we could then probably expose a PartialCasePath<State> instead of a whole State and switch over this.