[swift-dev] New warning message while switching on an enum

[Robert Widmann]

Is there a catch-all to query for such casts (sorry, I'm away from my computer at the moment).

~Robert Widmann

2017/05/09 16:40、Jordan Rose <jordan_rose at apple.com> のメッセージ:

> 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 <devteam.codafi at gmail.com> 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 <jordan_rose at 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.codafi at 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_rose at 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.codafi at 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_rose at 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. Thanks for catching this!
>>>>>>> 
>>>>>>> Jordan
>>>>>>> 
>>>>>>> 
>>>>>>>> On May 9, 2017, at 07:09, Pushkar N Kulkarni via swift-dev <swift-dev at 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 at swift.org
>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170509/29227e8a/attachment.html>