Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[SR-8893] AnyObject constraint on generic type parameter doesn't work when a protocol type is passed as an argument #51399

Closed
swift-ci opened this issue Oct 2, 2018 · 4 comments
Closed

[SR-8893] AnyObject constraint on generic type parameter doesn't work when a protocol type is passed as an argument #51399

swift-ci opened this issue Oct 2, 2018 · 4 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Oct 2, 2018

Previous ID SR-8893
Radar None
Original Reporter revolucent (JIRA User)
Type Bug
Status Resolved
Resolution Duplicate
Environment

Xcode 10, Swift 4

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee None
Priority Medium

md5: b292e01db2f57940a4b5106a8aed05b9

duplicates:

  • SR-55 non-@objc protocol existentials do not conform to their own protocol type

Issue Description:

When passing a protocol as an argument, it may be useful to know whether it has reference semantics, but there does not appear to be a way to do this in Swift. The following code does not compile but should:

protocol Foo: class {
}

func use<P: AnyObject>(type: P.Type) {
}

// Does not compile
use(type: Foo.self)
@belkadan
Copy link
Contributor

belkadan commented Oct 2, 2018

Interesting. @slavapestov, is there a reason we can't support this for types, or did we just not get to it?

@slavapestov
Copy link
Member

An existential metatype does not have a representation compatible with AnyObject.Type either. It's the same limitation.

@belkadan
Copy link
Contributor

belkadan commented Oct 2, 2018

Oops, right, of course.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Oct 2, 2018

Comment by Gregory Higley (JIRA)

In this particular case, it's an even more unfortunate limitation, because reference semantics are different from non-reference semantics, and it still would be nice to know at compile time which one we're dealing with in the case where we don't have an instance.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@slavapestov @belkadan @swift-ci