Consider two Swift enums:
enum Foo: Int { case bar } @objc enum Baz: Int { case qux }
If I were to print each case of these enums, I would expect the same result. Instead, I see something unexpected:
print(Foo.bar) // "bar\n" print(Baz.qux) // "Baz\n"
Why does printing a case of an @objc enum print the enum name, while printing the case of a pure Swift enum print the actual case name? Does adding @objc change the debug description of the enum?
That is because @objc enums are "C-compatible enums", which intentionally do not emit any reflection information about their cases.
Since Swift is open source, we can nose around to see this for ourselves:
That's one version of "why", the implementation-focused. Now, let's step back one level and ask, why was it implemented this way? The comment by the emitCaseNames function for the C-compatible enums explains this: C-compatible enums don't guarantee a mapping from the enum raw value back to the tag, because, unlike the Swift-native enums, they can have multiple cases that all have the same raw value.
Now, if you try to declare an enum in Swift that duplicates raw values, you'll get your hand slapped and a compiler error. But you should be able to create such an enum by declaring the enum in Obj/C and then importing it into Swift over the bridge.