-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[PrintAsObjC] Put "copy" in the property decls for value types. #3141
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
[PrintAsObjC] Put "copy" in the property decls for value types. #3141
Conversation
Bridged value types are implicitly copied as part of bridging. This isn't 100% correct because it doesn't handle bridged types that /don't/ conform to NSCopying, but there aren't any of those today and there probably shouldn't be. rdar://problem/26917017
@swift-ci Please test |
@parkera, @phausler, @DougGregor: on this note, do you think NSCopying should be a requirement for _ObjectiveCBridgeable? It might not make sense for a non-value type, and isn't strictly necessary for many of the conformances, but I don't think we want to encourage bridging classes to other classes. |
We require it for all of our value types but I don't know if it extends to everything else. |
Conceptually isn't CF to NS types a bridge in a similar manner? But they are reference type to reference type. Sent from my iPhone
|
Hm, interesting. I think we currently represent the CF to NS bridge with magic™ (based on the In any case, this wasn't going to stop me from merging anyway. This is still a net improvement and matches what we're doing today. |
We sometimes form aliasing references to unrelated class types, usually as a sort of fake incomplete type when we don't want to import Foundation. As long as we never access stored properties of those classes within Swift code it's ok. e.g. I don't think we can access any NSString stored properties from Swift. |
I was more worried about |
Right. I made a note of it. If both types are classes and are known not to have a subclass relationship, then the rule says they cannot alias. We will need make exceptions for certain bridged types, or provide some kind of annotation on one of the classes that opts out of the aliasing rule. |
Yeah, this looks good to me. The NSCopying requirement on _ObjectiveCBridgeable's associated class type conceptually makes sense---you shouldn't be bridging a value type or a non-copyable class type---but we can't actually do that without importing the ObjectiveC module into the Swift standard library (or applying some funny layering trick) |
Bridged value types are implicitly copied as part of bridging, so we should be using
@property (copy)
instead of the defaultassign
orstrong
.This isn't 100% correct because it doesn't handle bridged types that don't conform to NSCopying, but there aren't any of those today and there probably shouldn't be.
rdar://problem/26917017
Before merging this pull request to apple/swift repository:
Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
Validation Testing
Lint Testing
Note: Only members of the Apple organization can trigger swift-ci.