[swift-corelibs-dev] Possible Proposal: Foundation corelibs API change necessary for NSPredicate
Philippe Hausler
phausler at apple.com
Mon Dec 14 12:09:16 CST 2015
This might actually just be a bug in our annotations of what is nullable and what is not. I would have to double check but it seems pretty reasonable that it should have been nullable to begin with.
> On Dec 14, 2015, at 10:06 AM, Kevin Lundberg via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
>
> 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 <mailto:kevin at klundberg.com>
>
> _______________________________________________
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20151214/51f60d99/attachment.html>
More information about the swift-corelibs-dev
mailing list