Skip to content

[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

Merged

Conversation

jrose-apple
Copy link
Contributor

Bridged value types are implicitly copied as part of bridging, so we should be using @property (copy) instead of the default assign or strong.

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:

  • Test pull request on Swift continuous integration.

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

Platform Comment
All supported platforms @swift-ci Please smoke test
All supported platforms @swift-ci Please smoke test and merge
OS X platform @swift-ci Please smoke test OS X platform
Linux platform @swift-ci Please smoke test Linux platform

Validation Testing

Platform Comment
All supported platforms @swift-ci Please test
All supported platforms @swift-ci Please test and merge
OS X platform @swift-ci Please test OS X platform
OS X platform @swift-ci Please benchmark
Linux platform @swift-ci Please test Linux platform

Lint Testing

Language Comment
Python @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

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
@jrose-apple
Copy link
Contributor Author

@swift-ci Please test

@jrose-apple
Copy link
Contributor Author

@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.

@parkera
Copy link
Contributor

parkera commented Jun 22, 2016

We require it for all of our value types but I don't know if it extends to everything else.

https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/ReferenceConvertible.swift#L19

@phausler
Copy link
Contributor

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

On Jun 22, 2016, at 10:19 AM, Jordan Rose [email protected] wrote:

@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.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@jrose-apple
Copy link
Contributor Author

Hm, interesting. I think we currently represent the CF to NS bridge with magic™ (based on the objc_bridge Clang attribute), and we have to special case it in other parts of the compiler as well (a CFString and an NSString can alias, for example—cc @atrick). But I see the point.

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.

@jrose-apple jrose-apple merged commit d83db61 into swiftlang:master Jun 22, 2016
@jrose-apple jrose-apple deleted the value-types-are-copy-properties branch June 22, 2016 20:28
@atrick
Copy link
Contributor

atrick commented Jun 22, 2016

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.

@jrose-apple
Copy link
Contributor Author

I was more worried about UnsafeMutablePointer<CFString> and UnsafeMutablePointer<NSString>. These need to be considered potentially-aliasing.

@atrick
Copy link
Contributor

atrick commented Jun 23, 2016

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.

@DougGregor
Copy link
Member

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants