iOS countForFetchRequest & Swift 2

[Mascots]

The delectation for executeFetchRequest was converted for Swift 2:

func executeFetchRequest(_request: NSFetchRequest) throws -> [AnyObject]​

while countForFetchRequest still expects an error pointer passed through it:

func countForFetchRequest(_request: NSFetchRequest, errorerror: NSErrorPointer) -> Int​

So like, did Apple just forget to convert or do you think there was a reason?

 

[iphonedude2008]

The delectation for executeFetchRequest was converted for Swift 2:

func executeFetchRequest(_request: NSFetchRequest) throws -> [AnyObject]​

while countForFetchRequest still expects an error pointer passed through it:

func countForFetchRequest(_request: NSFetchRequest, errorerror: NSErrorPointer) -> Int​

So like, did Apple just forget to convert or do you think there was a reason?

No sure. That seems weird that they would forget to convert it. Maybe someone else knows why apple would want to leave the old error pointer stuff in? Obj c compatibility is the only thing I could possibly think of. After all, most of their code is still in obj c.

 

[Mascots]

They didn't give a rat's about BC with Swift 2, so it seems way inconsistent.

I know Core Data is suffering during the Swift migration, but I honestly think they just overlooked it.

 

[grandM]

They didn't give a rat's about BC with Swift 2, so it seems way inconsistent.

I know Core Data is suffering during the Swift migration, but I honestly think they just overlooked it.

suffering?

 

[1458279]

I see it reads: "throws -> [AnyObject]"
Does that mean that AnyObject would contain the error? Maybe it's because one executes a command and the other returns an Int. In other words, it has to have a way to get to the error object, either by a return or a pointer.

 

[Mascots]

suffering?

There have been many issues introduced with Swift in Core Data.
From the top of my head
- Broken Xcode NSManagedObject subclass generation
- Misdocumented side effects of namespacing, pretty much requiring your model to be a framework if you test or use an extension
- Awkward and inconsistent syntax, mostly from the way they exploit Obj-c's runtime which worked well at one point.
- Inconsistent adaption to Swift methods 😉

Overall, there's just a lot of edge cases that you'll only run into while working with it, often requiring a bit of forethought and research.

I still like it though.

 

[Mascots]

I see it reads: "throws -> [AnyObject]"
Does that mean that AnyObject would contain the error? Maybe it's because one executes a command and the other returns an Int. In other words, it has to have a way to get to the error object, either by a return or a pointer.

No error pointer in Swift 2 - the throws signifies an error may be thrown while [AnyObject] refers to the casted NSManagedObject in an array, only. You simply catch the error and don't have to handle a pointer.

It's in sharp contrast to Objective-C's way, which still seems to affect countForFR.