Not a huge number of changes this week.
Having troubles opening Beta 6? Gus Mueller has an answer. Make sure to adjust the name of the app as needed, especially if you’ve renamed it as I have to keep your Keyboard Maestro macros running:
xattr -d com.apple.quarantine ./Xcode6-Beta.app
Goodbye .hasValue. I loved you In Xcode 6 beta 6, (I’m sure there’s another 6 in there somewhere to make this the release of the beast) hasValue is gone. This makes me a little sad. Its semantic richness has been removed, a notes says “use != nil instead”. Syntactically fine, but the concept of “this container holds a payload” has gone away.
The positive test for optionalVariable.hasValue {…} will stick around, but a payload-check is now if optionalVariable == nil instead of if !optionalVariable.hasValue, which I found better told the story. The test against nil is handy and I don’t mind it but I don’t think it’s a superior option when evaluated against its brethren.
HomeKit accessory simulator Now you can pretend to turn lights off and on — even if you don’t own a fancy thermostat!
Foundation conformance updates. Remember all those T!’s I was recently complaining about, the ones that made no sense at all in Cocoa APIs? Many of them (officially a “large number”) have been audited for optional compliance. That means Beta 5 calls like sendAsynchronousRequest(request: NSURLRequest!, queue: NSOperationQueue!, completionHandler handler: ((NSURLResponse!, NSData!, NSError!) -> Void)!) will now better match real world use.
In Beta 6, this call has been updated to sendAsynchronousRequest(request: NSURLRequest, queue: NSOperationQueue?, completionHandler handler: ((NSURLResponse!, NSData!, NSError!) -> Void)?), so the handler closure is still completely borked but at least the primary parameters are more thoughtfully assigned. At some point they really need to either introduce a Results enumeration (with value and error) or fix this to all optionals.
PRO TIP: When filing radars about API migration regarding implicitly unwrapped optionals, include #IUO in the subject line. Apple requests that you do not file radars about APIs that remain wrong, only those that were improperly converted away from IUOs. So I’m completely at a loss about what to do here. Apple writes, “Do not file feature requests about APIs that are still marked as T!, we know about them.” Well, okay then.
Bitwise operators are more NSFriendly. Apple writes “RawOptionSetType now implements to BitwiseOperationsType, so imported NS_OPTIONS now support the bitwise assignment operators |=, &=, and ^=”
Strings append but won’t concatenate. Remember the changes to Arrays back in Beta 5 — the ones where you could append two arrays but not add a new item? It now applies to Strings as well. You cannot add characters to strings — convert them to strings themselves and then add them.
Better voiding through science. C APIs that use void* will preserve the Void typealias.
2 Comments
The problem was a defective build of Xcode 6 B6, they pulled off and now its online again.
https://devforums.apple.com/message/1025253#1025253
I miss hasValue, too… I have yet to find any good reason why it was removed, too. It seemed both more semantically (better reflected my intent) and also was easier to read (less !=, ==, etc. checks).