On Jan 9, 2018, at 4:46 PM, Jordan Rose <jordan_r...@apple.com> wrote: > Thanks for writing this up, Chris! I addressed the idea of making this an > arbitrary pattern in the revised proposal > <https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums-2/proposals/0192-non-exhaustive-enums.md#unknown-case-patterns>, > and the idea of not matching known cases in a "considered alternative" > <https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums-2/proposals/0192-non-exhaustive-enums.md#mixing-unknown-case-and-default>, > but in short: > > - Matching in arbitrary pattern positions is harder to implement and harder > to produce good diagnostics for. (Specifically, the former comes from having > to actually check the existing cases in the generated code rather than just > having an "else" branch.) I'm not inherently opposed to it if we can all > agree on what it means, but I don't think I have time to implement it for > Swift 5, so I'm not including it in the proposal.
I’m not sure what you’re saying here. This does slot directly into the existing pattern design: it is just a new terminal pattern node. Are you saying the SILGen/IRGen is more difficult and therefore you’re not interested in doing it even if it is the better design? If that is the case, then the conservatively correct thing to do (in my opinion) is to add no feature here: no “unknown case:” and no “case #unknown:’. Alternatively are you saying that you intend to support only the “case #unknown:” form exactly, but not the recursive cases? > - Matching known cases is a feature, not a limitation, to avoid existing code > changing meaning when you recompile. I'll admit that's not the strongest > motivation, though, since other things can change the meaning of existing > code when you recompile already. I’m not sure I understand this. The whole motivation for this feature is to notify people if they are not handling a “newly known” case. If they don’t care about this, they can just use default. > - FWIW I can't actually think of a use case for using this with `if case` or > anything else. I'm not against it, but I don't know why you would ever do it, > just like I don't know why you would mix `case #unknown` with `default` when > matching against a single value. Brent gave a simple example down thread. That said, I’m more concerned about keeping pattern matching simple and composable than I am about particular use cases (I agree the top level case in a switch on enum is the disproportionately important case). At some point we will hopefully extend pattern matching to support regexes and other things, we want to keep the design consistent. > That said, it sounds like people are happier with `case #unknown` than > `unknown case`, and that leaves things a little more consistent if we ever do > expand it to other pattern positions, so I'll change the proposal revision to > use that spelling. (And if anyone comes up with a nicer spelling, great!) Thanks! -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
