Right. I guess I should have asked: Are there any other kinds of patterns we consider exhaustive that have this structure?
~Robert Widmann > On May 9, 2017, at 2:23 PM, Jordan Rose <jordan_r...@apple.com> wrote: > > "as NSError" isn't a tautology, though—the original type is 'Error'. > Additionally, the presence or absence of a warning shouldn't affect > exhaustiveness analysis, which is currently an error when you get it wrong. > Warnings are things you can build with and fix later. > > Jordan > > >> On May 9, 2017, at 11:22, Robert Widmann <devteam.cod...@gmail.com >> <mailto:devteam.cod...@gmail.com>> wrote: >> >> We’ll warn if that kind of cast is a tautology, right? That leaves only the >> dynamic casts, which can’t be assumed exhaustive. >> >> ~Robert Widmann >> >>> On May 9, 2017, at 2:13 PM, Jordan Rose <jordan_r...@apple.com >>> <mailto:jordan_r...@apple.com>> wrote: >>> >>> It's neither a variable binding nor an expression pattern, right? It has to >>> be compared against the original type to know whether it's exhaustive or >>> not. (Consider "let error as NSError" in a catch clause, which should be >>> considered exhaustive.) >>> >>> Jordan >>> >>>> On May 9, 2017, at 11:12, Robert Widmann <devteam.cod...@gmail.com >>>> <mailto:devteam.cod...@gmail.com>> wrote: >>>> >>>> It’s mine, yep. It looks like it’s classifying the cast in the first >>>> pattern as a variable binding instead of an expression pattern. I’ll push >>>> a fix later. >>>> >>>> Thanks! >>>> >>>>> On May 9, 2017, at 1:52 PM, Jordan Rose <jordan_r...@apple.com >>>>> <mailto:jordan_r...@apple.com>> wrote: >>>>> >>>>> That looks like a bug to me, since of course the first pattern won't >>>>> always match. I suspect this is Robert's work on trying to make the >>>>> exhaustive checks better, https://github.com/apple/swift/pull/8908 >>>>> <https://github.com/apple/swift/pull/8908>. Thanks for catching this! >>>>> >>>>> Jordan >>>>> >>>>> >>>>>> On May 9, 2017, at 07:09, Pushkar N Kulkarni via swift-dev >>>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote: >>>>>> >>>>>> Hi there, >>>>>> >>>>>> I see a new warning message for switch statements on enums, like this >>>>>> one: >>>>>> >>>>>> enum Test { >>>>>> case one(Any) >>>>>> case two >>>>>> } >>>>>> >>>>>> let x: Test = .one("One") >>>>>> switch x { >>>>>> case .one(let s as String): print(s) >>>>>> case .one: break >>>>>> case .two: break >>>>>> } >>>>>> >>>>>> enum.swift:9:10: warning: case is already handled by previous patterns; >>>>>> consider removing it >>>>>> case .one: break >>>>>> >>>>>> >>>>>> I do not see this warning with the 04-24 dev snapshot. >>>>>> >>>>>> The warning goes away with the use of the wildcard pattern in the second >>>>>> case: >>>>>> >>>>>> switch x { >>>>>> case .one(let s as String): print(s) >>>>>> case .one(_): break >>>>>> case .two: break >>>>>> } >>>>>> >>>>>> >>>>>> I am wondering if this change is intentional, though it does make sense >>>>>> to me. Can someone please point me to the related commit? >>>>>> >>>>>> Thanks in advance! >>>>>> >>>>>> Pushkar N Kulkarni, >>>>>> IBM Runtimes >>>>>> >>>>>> Simplicity is prerequisite for reliability - Edsger W. Dijkstra >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> swift-dev mailing list >>>>>> swift-dev@swift.org <mailto:swift-dev@swift.org> >>>>>> https://lists.swift.org/mailman/listinfo/swift-dev >>>>>> <https://lists.swift.org/mailman/listinfo/swift-dev> >>>>> >>>> >>> >> >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
