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.

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-4451] type(of:) behaviour change from Swift 3.0.2 to Swift 3.1. #47028

Open
swift-ci opened this issue Mar 31, 2017 · 8 comments
Open

[SR-4451] type(of:) behaviour change from Swift 3.0.2 to Swift 3.1. #47028

swift-ci opened this issue Mar 31, 2017 · 8 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself good first issue Good for newcomers type checker Area → compiler: Semantic analysis

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-4451
Radar rdar://problem/31404284
Original Reporter razvandub (JIRA User)
Type Bug

Attachment: Download

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

md5: 59a922e46e7486ff5d399c2af0e0d2d8

Issue Description:

It seems that the behaviour of "type(of: )" has changed from Swift 3.0.2 to Swift 3.1 w.r.t. optional Any? closure parameters referenced as Any.

"type(of: oItem) as? T.Type" below returns "__NSCFString.Type" when using Swift 3.0.2 compiler and "nil" when using Swift 3.1 compiler.

import Foundation

internal extension Set where Element: NSObject {
    
    internal func items <T: NSObject> (ofType itemType: T.Type) -> Set<T>? {
        return NSSet(set: self).filtered(using: NSPredicate { (oItem: Any /* Note Any instead of Any? */, _) -> Bool in
            return nil != (type(of: oItem) as? T.Type)  // Swift 3.0.2 => true, Swift 3.1 => false.
            //                        return oItem is T // Swift 3.0.2 => true, Swift 3.1 => true.
        }) as? Set<T>
    }
}

let stringsOfTypeNSObject = (["1", "2"] as Set<NSString>).items(ofType: NSObject.self)

print(stringsOfTypeNSObject ?? []) // Swift 3.0.2 => [1, 2], Swift 3.1 => [].
@swift-ci
Copy link
Collaborator Author

Comment by Razvan Popescu (JIRA)

Attached playground.

@belkadan
Copy link
Contributor

I suspect it is our boxing behavior that's changed. @jckarter, thoughts?

@jckarter
Copy link
Member

If oItem contains an Optional then type(of: oItem) would give Optional<T>, which is never an NSObject.Type. Is that what's going on?

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 3, 2017

Comment by Razvan Popescu (JIRA)

@belkadan, @jckarter, thanks for the replies. @jckarter, yes, I would have expected that as well yet, however, if "NSPredicate" is constructed with

@jckarter
Copy link
Member

jckarter commented Apr 3, 2017

Yeah, it seems to me like that warning ought to fire here.

@jckarter
Copy link
Member

jckarter commented Apr 3, 2017

@swift-ci create

@rudkx
Copy link
Member

rudkx commented Mar 30, 2018

razvandub (JIRA User), if I understand correctly, the concern is that we do not emit a warning for the function conversion in something like this:

struct P {
  init(_ fn: (Any?, [String : Any]?) -> Bool) {}
}

let p = P { (a: Any, _) -> Bool in }

is that correct?

@swift-ci
Copy link
Collaborator Author

Comment by Razvan Popescu (JIRA)

@rudkx, the core issue was the change in type(of: oItem) behaviour/output when switching from Swift 3.0.2 to Swift 3.1+. Based on @jckarter's reply above, it looks like it may have been a Swift 3.0.2 bug. If that's the case and the Swift 3.1+ type(of: oItem) behaviour is correct, then yes, I would have expected a warning there. Thanks.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
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 good first issue Good for newcomers type checker Area → compiler: Semantic analysis
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jckarter @rudkx @belkadan @swift-ci