[swift-evolution] Handling unknown cases in enums [RE: SE-0192]

[Antoine Cœur]

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 at swift.org> a écrit :

> On Jan 9, 2018, at 4:46 PM, Jordan Rose <jordan_rose at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180110/bb1236d4/attachment.html>