I think any bridging conversion or upcast would count.
enum Foo {
case foo(NSFileManager)
case bar(NSString)
case baz(Int)
}
func test(x: Foo) {
switch x {
case .foo(let obj as NSObject):
print("totally legal")
case .bar(let obj as String):
print("also cool")
case .baz(let obj as Any):
print("I'm not sure why, but sure")
}
}
Jordan
> On May 9, 2017, at 11:29, Robert Widmann <[email protected]> wrote:
>
> 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 <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>>> <mailto:[email protected]>> 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 <[email protected]
>>>> <mailto:[email protected]>> 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 <[email protected]
>>>>> <mailto:[email protected]>> 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 <[email protected]
>>>>>> <mailto:[email protected]>> 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
>>>>>>> <[email protected] <mailto:[email protected]>> 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
>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-dev>
>>>>>>
>>>>>
>>>>
>>>
>>
>
_______________________________________________
swift-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-dev
