New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SR-2287] Forced downcast is inconsistent from Darwin to Linux from Any to AnyObject #44894
Comments
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
|
Why are you trying to |
And what do you mean that |
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
|
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:
@DougGregor, would it be possible to tweak the type checker to favor |
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 |
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) 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. |
Additional Detail from JIRA
md5: ad6c5e8f031f6b621cbc1834d19758fe
Issue Description:
example:
This will cause some severe bugs and regressions in swift-corelibs-foundation and will probably make code less portable.
The text was updated successfully, but these errors were encountered: