[swift-corelibs-dev] Possible Proposal: Foundation corelibs API change necessary for NSPredicate

[Kevin Lundberg]

I have a pending pull request that needs a little more work around NSPredicates, but in my testing on darwin foundation, I’ve discovered what appears to be an obj-c nullability annotation bug. When constructing a block predicate, the type of the block is this:

(AnyObject, [String: AnyObject]?) -> Bool

However, the type signature of evaluateObject(_:substitutionVariables:) is

(AnyObject?, [String: AnyObject]?) -> Bool

Note the optional AnyObject here. In Xcode 7.2 with swift 2.1, the following code causes an EXC_BAD_ACCESS signal when calling evaluateWithObject: in a playground:

let pred = NSPredicate(block: { (obj: AnyObject, bindings: [String: AnyObject]?) -> Bool in
    print(obj)
    return false
})
print(pred.evaluateWithObject(nil))

because obj is in fact optional here, but the type of the block does not allow for this.

There are two possible approaches here; removing the optional type from evaluateWithObject, or adding it to the block constructor for NSPredicate. Such a change is also presumably trivial to port back to darwin foundation, as that at minimum would need to merely change nullability annotations for these components of NSPredicate. These involve a public-api change which by my understanding needs to go through the swift evolution process.

Before sending this over to swift-evolution which is already pretty high-traffic, I wanted to float this here to make sure that this is appropriate for that process. Is it enough to draft a proposal outright or for comprehensiveness sake should I also send this out to that list to open discussion first?

Is there anyone on this list that has an opinion over which approach to take for changing the api here?

Thanks!

--
Kevin Lundberg
kevin at klundberg.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20151214/9710f46f/attachment.html>