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

[Philippe Hausler]

As a general rule of thumb we ❤️radars. In this case I have already filed a bug with the component owner since it clearly looks like this is perhaps a incorrectly annotated API. So a PR for this is quite reasonable to change to ? since it would be a bit difficult to implement else wise.

> On Dec 14, 2015, at 10:22 AM, Kevin Lundberg <kevin at klundberg.com> wrote:
> 
> Great, should I file a radar on bugreport.apple.com <http://bugreport.apple.com/> for this? And if it’s simple enough to fix that can I apply the same fix to the SwiftFoundation API as a PR without any extra process?
> 
> --
> Kevin Lundberg
> kevin at klundberg.com <mailto:kevin at klundberg.com>
>> On Dec 14, 2015, at 1:09 PM, Philippe Hausler <phausler at apple.com <mailto:phausler at apple.com>> wrote:
>> 
>> 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 <mailto: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 <mailto:swift-corelibs-dev at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev <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/d6a56ec2/attachment.html>