@jckarter?

This is causing unit test failures on Darwin builds of swift-corelibs-foundation (which is not built in CI currently)

a potentially more detailed failure example: (running on Darwin ToT swift)

class Foo {

}

class Bar : Foo {

}

let t: [String : Any] = [
    "bar" : Bar()
]

// the throws may be irrelevant but it is close to the actual code that is failing this way.
func thisReallyReturnsABar() throws -> AnyObject? {
    return t["bar"] as? AnyObject
}

guard let baz = try! thisReallyReturnsABar() as? Bar else {
    fatalError("Unexpected") // this is what currently hits
}
print("working correctly") // previous versions hit here

It is worth noting that the warning is at best a confabulation

test.swift:14:21: warning: conditional cast from 'Any?' to 'AnyObject' always succeeds
    return t["bar"] as? AnyObject

Why are you trying to as AnyObject on Linux?

And what do you mean that value as? AnyObject fails to convert properly on Darwin? It should always succeed now and have the same bridging effect as the unconditional as AnyObject.

The failure of `value as? AnyObject` is listed in the code example attached

It results in the fatal error on Darwin and hits the working correctly case on Linux (and offers no warning)

It may be that it's bridging the `Optional` to `AnyObject` by boxing rather than conditionally casting the inner value. Does:

t["bar"].flatMap { $0 as? AnyObject }

give the right behavior?

My concern is that this was existing code in swift-corelibs-foundation and the behavior is different from Linux to Darwin. One of the two is incorrect. I have a nasty #if os check to guard the behavior differential for now. And yes the flatMap works consistently between the two.

It does however still emit the warning with the flat map case

test.swift:15:42: warning: conditional cast from 'Any' to 'AnyObject' always succeeds

It's sort-of behaving "as designed", since id-as-Any means, well, anything can bridge to AnyObject including Optionals. I agree this is not the desired or expected behavior in this case. A couple things might mitigate it:

• If we do a conditional cast on an optional, we should probably favor the interpretation of as? AnyObject as looking through the optional and conditionally casting its payload if it has one, over the universal boxing bridge.

• Optional on Darwin might deserve to be _ObjectiveCBridgeable to its payload type, or NSNull if it happens to be nil. This would give you coherent behavior in this case (albeit with the warning on Darwin, which we could suppress), and would also allow collections of optionals to interoperate with ObjC as NS collections containing NSNull.

@DougGregor, would it be possible to tweak the type checker to favor T? as? AnyObject as conditionally unwrapping the optional?

I don't think we should bridge optional to NSNull. That is a pretty different concept than nullability. My concern is when code is written for Darwin platforms first, and then ported to other platforms developers will attempt to remove warnings; which in this case would make the code not portable.

What's your use case for checking whether something is AnyObject?

Because if the element is a structure like String or Array etc

I think your message got cut off…

The storage in the particular case that this was found in was storing a dictionary of strings to a heterogenous bag of items; Strings, Arrays, objects etc. Particularly the implementation for NSKeyedUnarchiver

What does it do with the information about whether something is an object? Can it be rephrased in terms of `Any` now?

The particular call site needs to decode an object of a class, so inherently the return value must be of the requested class (meaning it must be an AnyObject). But my worry is that if we have run across a quasi legitimate use case there is a definite potential that this will break pre-existing code in-the-wild and the resulting fixes suggested will result in un-portable code.

There are probably plenty more things we could do (given more time to work on them) to make this a non-issue in swift-corelibs-foundation but as it stands we will have a warning that is emitted that is misleading and "fixing" it will break the linux builds. I would need to take a while to look and see how much refactoring is needed to actually fix it to avoid the problem completely.

Here is the case where I am running across the issue (this fixes the unit test failures, but of course does not fix the underlying problem)
apple/swift-corelibs-foundation@a37cbdf

Per "id-as-Any means, well, anything can bridge", this is in the context of swift-corelibs-foundation which has no actual bridging, should this behavior be the case when Foundation is not imported?

Comment by Helge Heß (JIRA)

Also came across this as a hack-around for https://bugs.swift.org/browse/SR-6039.