Comment by Ling Guo (JIRA)

I came across the same issue:

protocol AProtocol {
    mutating func getPtr() -> UnsafeMutableRawPointer
}

extension AProtocol {
    mutating func getPtr() -> UnsafeMutableRawPointer {
        if self is AnyObject {
            return withUnsafePointer(to: &self, { unsafeBitCast($0.pointee, to: UnsafeMutableRawPointer.self) })
        } else {
            return withUnsafePointer(to: &self, { unsafeBitCast($0, to: UnsafeMutableRawPointer.self) })
        }
    }
}

cc @jckarter

This is correct, because everything bridges to AnyObject now. What you're trying to do using withUnsafePointer is undefined behavior. You can't preserve $0 beyond the duration of the closure. What are you trying to accomplish?

Ling's example is invalid, but 100mango's isn't.

is/as AnyObject always succeed for all types now. It's behaving as intended.

Right, but the report says the runtime is behaving differently.

@rjmccall has a fix for this in #4410

Comment by 100mango (JIRA)

Thanks for your quick reply. It make me wonder how to detect value type and reference type in Swift now. One of my framework SwiftNotificationCenter need to detect value type and reference type. Because value type is copied when it is assigned to a variable or constant, or when it is passed to a function.So it can't be participated in one to many communication.Cocoa' NotificationCenter can't add value type as observer too.

You can still statically constrain parameters to AnyObject so that they statically require classes, which would be appropriate for observers. Your observers probably need to also have methods of some sort, so you probably want a class-constrained protocol.

Does the PR fix the case reported in my dupe SR-2498, wherein the compiler claims that foo is AnyObject always returns true but if you actually execute the code at runtime, it evaluates to {{false]}?

Eridius (JIRA User) Yeah, John's fix should address that.

Comment by Rudolf Adamkovič (JIRA)

This bug is still present in Xcode 8.3.1 (8E1000a):

struct SwiftBug {

    struct TestStruct {}

    func test() {

        //warning: 'is' test is always true
        if TestStruct() is AnyObject {
            print("pass")
        }

    }

}

@jckarter Can this behaviour be made explicit? Something like `ObjCRefBox(TestStruct())` (because IMO, `SwiftValue` is a poor class name to expose publicly)? It's really confusing to new people, and relatively hard to explain. It completely muddies the waters on `Any` vs `AnyObject`.

There were many other implicit bridging behaviours, like `NSString` to `String`, that were way more straight-forward than this one, but even they were changed to require an explicit coercion.

"SwiftValue" is an implementation detail; the name of the class Swift happens to use to box values when bridging to ObjC could change at any time. It's exactly as explicit as the other bridging behaviors; Swift won't just convert something to AnyObject unless you ask it to with `as AnyObject`.

@jckarter Thanks for your response. " It's exactly as explicit as the other bridging behaviors; Swift won't just convert something to AnyObject unless you ask it to with `as AnyObject`." Ah yes, I didn't realize that.

I guess my issue is that `is` doesn't operate on the value as it already exists, but it considers potential bridging that's available. If you have a `testStruct: TestStruct`, or a `str: Swift.String`, then `testStruct is AnyObject` and `str is NSString` both counterintuitively return true. Not because those values are those types, but because they could be bridged to be.

I think a lot of the confusion around this could be alleviated if `is` didn't consider bridging behaviour, and answers more directly about precisely what it was asked about.