[SR-2620] Conditional Downcast from AnyHashable to [file]private Protocol Fails Unless Going Through Intermediate Internal/Public Protocol

[itaiferber]

Previous ID	SR-2620
Radar	rdar://problem/28281488
Original Reporter	@itaiferber
Type	Bug

Environment

Running a recent internal build of macOS Sierra, with a recent internal build of Xcode, with a pre-built toolchain from swift.org (built 2016-09-06).

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, Runtime
Assignee	None
Priority	Medium

md5: cec9ad937be41dd8fe2810f062273465

relates to:

• SR-14064 Accessing Static Member on Downcast Type not Calling Overridden Implementation

Issue Description:

In my current project, I am processing data by mapping keys and values in a dictionary; the keys and values I get are type-erased as AnyHashable and Any, respectively, and I need to check if the types passed in adopt a protocol A, adopt a more specific, fileprivate protocol D (which inherits from A), or neither.

Checking this should be relatively easy — conditionally downcast to D; if that fails, try to downcast to A; if that fails, then the value conforms to neither protocol.
However, downcasting from the AnyHashable key behaves differently than the Any value; even when the key is a D, the downcast to D fails, and the downcast to A succeeds. The value, when a D, always downcasts correctly. However, the key does successfully downcast to a D if first cast to an A.

The code below shows a simplified example of the problem (the code prints "A![](", then "D)"):

// Functionality to do A
protocol A {
    func doA() throws
}

// Functionality to do B
protocol B {
    static func doB() throws -> Self?
}

// Functionality to do both A and B
protocol C: A, B {}

// A marker + hidden implementation for specific types.
fileprivate protocol D: C {}
extension D {
    func doA() throws {
        fatalError()
    }
    
    static func doB() throws -> Self? {
        fatalError()
    }
}

// Specific types which support this behavior.
extension String: D {}

// Data is exposed as AnyHashable (in reality, as a key in a dictionary)
let s = "Hello, world!" as AnyHashable

// Direct conditional cast from String → D fails
// Conditional cast from String → A succeeds
if let d = s as? D {
    print("D!")
} else if let a = s as? A {
    print("A!")
}

// Conditional case from String → D through A succeeds
if let d = (s as? A) as? D {
    print("D!")
}

If the declaration of s is changed to

let s = "Hello, world!" as Any

then "D!" is printed twice.

If necessary, I can file as a Radar with additional internal information and attach a URL.

[itaiferber]

Doing additional testing, it appears that this behavior manifests because D is declared fileprivate. Declaring it to be internal or public causes the direct conditional cast to succeed.

[itaiferber]

It looks like this happens for any fileprivate or private protocol. The following code fails as well:

fileprivate protocol A {}
extension String: A {}

let s = "Hello, world!" as AnyHashable
print("\(s is A)")

if let a = S as? A {
    print("A")
} else {
    print("Not A")
}

In this case, if there is no public protocol up in the hierarchy to cast to (like in my example), you have to work around the issue by doing something like (s as Any) as? A.

[belkadan]

@jckarter, any ideas? I wouldn't be surprised if AnyHashable didn't work with downcasts like this at all, but to only work with non-file-scoped protocols seems very strange.

[jckarter]

I'm surprised this ever works. I don't think this problem is specific to AnyHashable; in general the runtime does not try to work its way back up to protocol types IIRC. It may be that the optimizer or earlier peepholes manage to catch some cases that ought to work in theory.

[jckarter]

Specifically, the generally problematic case we have is when casting to a protocol that a bridged type or class conforms to when we have a value of the type at the other end of the bridge—for example, casting an 'Any' containing a 'String' to 'NSCopying' will fail, even though in theory we should be able to bridge to 'NSString' then find the 'NSCoding' conformance on that representation. Since 'AnyHashable' eagerly bridges the underlying value in many cases, it may be that the value inside is on the wrong side of the bridge for the protocol being cast back to.

[itaiferber]

FWIW, it looks like any and all protocol casts from AnyHashable fail on the public release of Xcode 8 (which I just installed on my work laptop), so at least the behavior there is consistent (which is good, no matter the behavior). The workaround there is (s as Any) as? A.

Though I have to admit that as a user, this behavior is pretty surprising. Is this an issue with my expectations?
The reason AnyHashable exists, AFAICT, is that it is a workaround for not being able to declare an [Any: Any] dictionary (since Any is not guaranteed to be Hashable, and it is impossible to use Hashable as a type constraint to create a [Hashable: Any] dictionary), no? If so, as a user, I expect AnyHashable to work much like Any would: "I can't really control the types which go in here (or there is no common types in their hierarchy), but please hold anything I give you as long as it is hashable." In that sense, I would expect the "please help me figure what type is being contained here in the first place" behavior that Any has, downcasts and all.

Those are, at least, my expectations as a 3rd-party user who might not know the internals of AnyHashable and its implementation. Whether or not those expectations match reality is something else, but it's worth mentioning. I am willing to accept non-intuitive behavior as long as it is consistent, and has good reason to be the way it is. Certainly, I see how bridging could throw a wrench in how protocol conformance should work here, but I think it would be fair to have AnyHashable work as Any would in that case (i.e. attempting to cast a String to NSCoding should rightfully fail in my opinion). I know there is likely good reason for AnyHashable to bridge eagerly, but I'm curious — what is that reason?

[jckarter]

Your understanding is correct. This is definitely a bug we ought to fix. The reason AnyHashable bridges eagerly is that we need to maintain a consistent hashing definition for the dictionary when used as an NSDictionary from Objective-C or as a Dictionary in Swift. Swift and ObjC have different definitions of string equality (Swift is Unicode correct, where ObjC only compares code units), and some Swift types bridge to ObjC classes with different hashing implementations; for instance, NSNumber needs to be able to hold a value of any boolean or numeric type, so its hashing algorithm needs to be different from just Int or Double in Swift. The eager bridging ensures we can efficiently compute a consistent hash for both Swift and ObjC containers.

[itaiferber]

Okay, figured. That makes sense, thanks!

[tbkka]

Did a little experimenting: If you use the function below to do the cast, it forces the cast to occur at runtime, which seems to work correctly. So this seems to be an issue in the compiler that causes it to optimize the cast away.
```
func dynamicCast<T,U>(_ value: T, to: U.Type) -> U? {
return value as? U
}
```