[SR-6811] Properties in ObjC protocol to Swift 4

[swift-ci]

Previous ID	SR-6811
Radar	rdar://problem/50319752
Original Reporter	marco (JIRA User)
Type	Bug

Attachment: Download

Environment

Xcode Version 9.2 beta (9C34b)

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, ClangImporter
Assignee	None
Priority	Medium

md5: ac75ea24f10428a371bce7f5da5a12b8

Issue Description:

If ProtocolA defines a property of type NSObject<ProtocolB>*, the Swift interface shows the property with type ProtocolB rather than NSObject & ProtocolB.

If the property is of type NSString<ProtocolB>*, the Swift interface loses the protocol information and just converts the property to type String.

What am I missing? It looks like the Swift conversion either loses the class or protocol information rather than keep them both with '&'.

I've attached an example project that shows the issue.

[belkadan]

Unfortunately, Objective-C protocols can't be combined with the Swift value types like "String", which do not have the same representation or semantics as NSString. We decided it was more important to preserve the bridging behavior than the protocol in the general case, but there have been requests to allow APIs to "opt out" of bridging in some particular instance, using some kind of annotation. I'll group this with that.

[swift-ci]

Comment by Marco Sero (JIRA)

Thanks for the explanation Jordan.

But how about the NSObject case? The Swift interface loses that information (the class, not the protocol).

[belkadan]

Ah, that one's been fixed in Swift 4. Make sure you're actually compiling as Swift 4, though, rather than using the Swift 3 compatibility mode.

[swift-ci]

Comment by Marco Sero (JIRA)

I am pretty sure I am compiling as Swift 4. You should be able to verify it in the attached example project.

[belkadan]

Ooh, you're right. It looks like we're still turning NSObject <ProtocolA> * into id <NSObject, ProtocolA>, which in this case is just id <ProtocolA>, on the grounds that "NSObject" usually doesn't add much. @DougGregor, what do you think? Is this still something we could change for Swift 5?