For example, CGImageSourceCreateWithURL() returns an Unmanaged<CGImageSource>!. You can't pass that object to CGImageSourceCreateImageAtIndex(), because it expects a CGImageSource!. Instead, you have to call takeUnretainedValue() on the Unmanaged to extract the raw pointer. Not terribly difficult, just mildly annoying and not well documented. In C/ObjC, you'd just take the return value of the first function and pass it right into the second.
Another example: CMSampleBufferGetImageBuffer() returns a CVImageBuffer!. And CVPixelBufferLockBaseAddress() takes a CVPixelBuffer! as its argument. In C/ObjC, CVPixelBufferRef is typedef'd to CVImageBufferRef, but that doesn't carry over in Swift. I tried to figure out the opaque-pointer voodoo required to convert from one to the other, and eventually gave up, wrote the function in Objective-C, and moved on.
Swift is shaping up to be an excellent language, but at this point, the casting/wrapping/unwrapping hurdles make it difficult for newcomers and experienced developers alike to take advantage of Apple's 15+ year corpus of powerful APIs.
But looking back, the first versions of ObjC were also kind of tedious (no @property declarations, no blocks, etc) and it's gone a long way.
Putting snark to one side, is it a general principle that languages evolve/develop more quickly now than in olden times...
There's a teaser at the end that there will be a follow-up article about UnsafePointer.
I just hope they hurry up and post it soon. I have half a large app that relies on UnsafePointers, and I could really use some clear documentation to reassure myself that I'm not abusing them.
I've not written any Swift code yet, so can someone enlighten me -- is this actually true? This seems unnecessarily restrictive (and absurd -- Swift can't tell if a pointer's being read?)
Swift can tell from static analysis if it might be read at compile time and raise an issue if it isn't initialised on all oaths to the access. If passed as an inout parameter it has to assume it may be read[0] and for safety require that it must be initialised.
[0] at least if it is calling into a library even if it can check the current version it couldn't know for sure that a different library version won't behave differently.
Isn't the 'maybeError' var being used uninitialized in the example right about this passage?
