<div dir="ltr"><div style="color:rgb(33,33,33)">And what about, as an alternative:</div><div style="color:rgb(33,33,33)"><br></div><div style="color:rgb(33,33,33)"><div>case (_, #unknown): … matches any int and any unknown enum case ...</div><div>case _: … matches anything ...</div><div><br></div><div>Then it clearly goes the "pattern matching" way.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">Le mer. 10 janv. 2018 à 14:17, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">On Jan 9, 2018, at 4:46 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>> wrote:</div><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Thanks for writing this up, Chris! I addressed the idea of making this an arbitrary pattern <a href="https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums-2/proposals/0192-non-exhaustive-enums.md#unknown-case-patterns" target="_blank">in the revised proposal</a>, and the idea of not matching known cases in <a href="https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums-2/proposals/0192-non-exhaustive-enums.md#mixing-unknown-case-and-default" target="_blank">a "considered alternative"</a>, but in short:</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">- 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.</div></blockquote><div><br></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div>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? </div><div><br></div><div>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:’.</div><div><br></div><div>Alternatively are you saying that you intend to support only the “case #unknown:” form exactly, but not the recursive cases?</div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><br></div><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">- 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.</div></blockquote><div><br></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div>I’m not sure I understand this. </div><div><br></div><div>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.</div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">- 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.</div></blockquote><div><br></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div>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). </div><div><br></div><div>At some point we will hopefully extend pattern matching to support regexes and other things, we want to keep the design consistent.</div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">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!)</div></blockquote><br></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div></div><div>Thanks!</div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><br></div><div>-Chris</div><div><br></div><br></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div>