> On Jan 9, 2018, at 22:17, Chris Lattner <clatt...@nondot.org> wrote:
> On Jan 9, 2018, at 4:46 PM, Jordan Rose <jordan_r...@apple.com 
> <mailto: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.

Notify, yes. Error, no. It's a design goal that adding a new case does not 
break source compatibility in addition to not breaking binary compatibility 
(because people don't like editing their dependencies) and therefore the 
behavior has to be defined when they recompile with no changes.

(This should also cover why it's more difficult to implement both diagnostics 
and SILGen for it.)


>> - 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

Reply via email to