Comment by Fredrik Tõnisson-Bystam (JIRA)

I just had an idea after posting this and tested it:

Creating a new "macOS command line tool" in Xcode 12.1 and running the code in there ALSO made it work "as expected". As in this printing true instead of false:
print(a is B.Type)

@swift-ci create

There are a number of bugs in dynamic casting (which includes the `is`, `as!` and `as?` operators) in Swift 5.3. Many of these will be fixed in the next release as a result of PR #33561 (#33561 and related work.

If you could, I'd appreciate if you could test two things:

1. Repeat your tests with both debug and optimized build settings, as many of the bugs that were fixed caused different behaviors for debug and optimized builds.
2. Test with one of the recent toolchains from the "main" branch available on swift.org, which should fix most of those bugs

A more subtle issue here is the confusing behavior of `.Type`: Your report mentions `B.Type` and `Fruit.Type`. These are entirely different things: Because `Fruit` is the name of a protocol, `Fruit.Type` is the "existential metatype" for `Fruit`. In contrast, `B` is a generic type variable, and `B.Type` is the metatype for whatever is bound to that variable. In your example where `B` is bound to the protocol type `Fruit`, `B.Type` is the same as `Fruit.Protocol` and is entirely unrelated to `Fruit.Type`.

For a more detailed explanation of how casting in Swift is supposed to work (and should work in the next release), you can see the new Dynamic Casting Spec

In the current `main` branch, which includes the updated casting logic, the following test passes in both debug and release builds:

  func check<A, B>(a: A.Type, b: B.Type) -> Bool {
    return (a is B.Type)
  }
  protocol Fruit {}
  struct Apple: Fruit {}
  expectFalse(check(a: Apple.self, b: Fruit.self))
  expectFalse(Apple.self is Fruit.Protocol)
  expectTrue(Apple.self is Fruit.Type)

Based on the casting specification, I believe this is the correct behavior. In particular, note that the first two `expectFalse` here are testing the same thing; the last `is Fruit.Type` is a completely different test. Based on your description above, it sounds like you were seeing this behavior in some circumstances but not all.

Note that this behavior depends both on the compiler and on runtime libraries that are bundled with Apple operating systems. So you should see this behavior once both Xcode and the OS have these updates.

Comment by Fredrik Tõnisson-Bystam (JIRA)

Right! Thanks for the clarification.

A more subtle issue here is the confusing behavior of `.Type`: Your report mentions `B.Type` and `Fruit.Type`. These are entirely different things: Because `Fruit` is the name of a protocol, `Fruit.Type` is the "existential metatype" for `Fruit`

I initially thought that this was the case too - but then when the things behaved differently when I tried it by using `swiftc` I decided to post it here anyway.

Great to see it being resolved, and now I know what the expected behaviour is in the future. Thanks! �