And what about, as an alternative: case (_, #unknown): … matches any int and any unknown enum case ... case _: … matches anything ...
Then it clearly goes the "pattern matching" way. Le mer. 10 janv. 2018 à 14:17, Chris Lattner via swift-evolution < swift-evolution@swift.org> a écrit : > 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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
