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
ke...@klundberg.com
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
