You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unless I'm mistaken, I think the true problem lies in the runtime; after checking to see if the value conforms to CustomStringConvertible, it should then check its bridged type for conformance (in a way, it's a similar issue to https://bugs.swift.org/browse/SR-3871 where the bridged type isn't checked for protocol conformance).
The reason this particular bug isn't encountered with as? and as! (though it is with is), for example:
is because such bridging coercions are caught and "filled in" at compile time rather than relying on the runtime. I don't believe we can do the same thing in pattern matching though, so I think the runtime is the place to fix this.
Environment
> swift --version
Apple Swift version 4.0.3 (swiftlang-900.0.74.1 clang-900.0.39.2)
Target: x86_64-apple-macosx10.9
(I'm in Xcode Version 9.2 (9C40b) but I don't think that's relevant)
Additional Detail from JIRA
md5: aa483efddb27c4b86b69f8a69c2f5c96
Issue Description:
If I create this enum
and implement CustomStringConvertible like this:
The compiler considers this to be exhaustive.
This is not the case i.e.
doesn't match any of the cases in the switch. This causes, erm, unpredictable behaviour.
Also, if I add a case to cover Error types which don't implement CustomStringConvertible, the compiles warns me that it is unnecessary. i.e. adding
causes "Case is already handled by previous patterns; consider removing it"
The text was updated successfully, but these errors were encountered: