Archive for August, 2014

Swift: What does 1.0 mean?

Been chatting about 1.0 — when it’s coming, what it will involve. The only thing that seems likely is that 1.0 will compile for 8.0, not that 1.0 will be code stable or act as a language development endpoint. Chris Lattner wrote, “Our goal for Swift 1.0 is for *apps* to be binary compatible with the OS, not for Swift 1.0 frameworks to be compatible with swift 2.0 frameworks.  The formal goal (what we’re shooting for) is relatively straight-forward, because apps are hemespherically sealed, and there is almost no dependence of swift 1.0 apps on the OS.”

I asked Lily Ballard about when he saw Swift debuting. He told me, “I’m assuming 1.0 will be live when Xcode 6.0 is released, which I’m assuming has to be done for iOS 8. But that seems awfully soon for Swift, so maybe that won’t actually be the case. Or maybe they’ll do a 1.1 soon after to fix a lot of this stuff.” What everyone can agree on is that iOS 8’s timeline is way too early for Swift, and Apple reserves the right to continue to grow the language in a way that will keep breaking code.

It’s a very odd time to be a tech writer, with an interest in eventually writing about Swift (in my mind, my opus will be called A Swift Kick in the Ass. Dibs.) because to date Apple has continued to update its Swift Programming Language volume at each beta iteration. I assume this will continue as the language continues its evolution and development, which leaves the door open for getting-up-to-speed tutorials, best practices, and tips/tricks but excludes the standard-reference crowd who would be otherwise competing with the Word of Apple.  As a side note, readers expecting Apple-style auto-updating texts will be disappointed by the economics and realities of the tech writing world.

For now, it’s a swiftly moving target (pardon the pun — but yes, it was intentional) trying to keep up with where the language is and where it will be. It’s surprising how much keeps changing beta to beta, in terms of how much code even in a core set of routines needs to be re-written and re-thought through.

Over time playing with the language, what stands out the most though is how often the Swift language doesn’t really fit the Cocoa workflow with its requests, errors, and optional results. There are apparently bunches and bunches of radars for Result types filed with Apple. On the whole, the Cocoa libraries don’t take full advantage of Swift’s generics and enumerations, and other data types because they weren’t written to. Moving to Swift is like bending your head sideways through Rust and F# and all those other cool but psychedelic languages. It’s taking me time, but some of this stuff is starting to sink in and make me look at Swift as a destination of its own rather than just another way to get at the familiar APIs.

The machine-translated APIs don’t help reinforce confidence. They’re full of confusing choices and things that just seem wrong. I’ve started bypassing type inferencing when using Cocoa APIs. I document what I expect to receive, despite the visual redundancy. Upside, it’s giving some of the devs over in #swift-lang some good chuckles.

The more I use Swift, the more I think the Cocoa community should be looking at it as a long-range target. Sure, you’ll be able to develop and submit apps in it sometime soon, but it would probably be a really bad choice to do so for any team serious about maintainable, stable code for the next year at least.

Swift: Beta 5 is alive

Some highlights.

Print and println now produce gutter results

Screen Shot 2014-08-04 at 11.42.45 AM

 

Coalescing is now available:

Screen Shot 2014-08-04 at 11.44.04 AM

Interesting results when you use optionals on both sides of the ?? even though this is theoretically an error (“takes an optional on the left and a lazily-evaluated non-optional expression on the right.”)

Screen Shot 2014-08-04 at 11.47.25 AM

You can now compare optionals to nil with == and != even if the underlying element doesn’t conform to Equatable. This applies across all optionals. Similarly, Optionals are no longer BooleanType conforming, so you can’t say if (optional). Instead, use if (optional == nil) or if (optional != nil).

The unwrapping operator (!) can be used in assignments, or “assigned through” with mutating methods and operators: The release notes mention that  “properties that are optional as a result of lookup through AnyObject cannot be mutated yet.”

Screen Shot 2014-08-04 at 11.56.52 AM

 

Note that in practice these seem to be a little flaky in my tests.

Screen Shot 2014-08-04 at 12.00.37 PM

Conformance Audits. UIView, NSView, UIFont, UIApplicationDelegate “have been audited for optional conformance, removing most implicitly unwrapped optionals from their interfaces.”  Still lingering issues in other classes but the “changes in Beta 5 are simply the first step; more refinements to the SDK will come in future betas.”

Screen Shot 2014-08-04 at 11.51.10 AM

Operators. Some big changes here. What was “operator prefix”, for example, is now “prefix operator”. Same for the other operator orders.

prefix operator  %% {}
prefix func %% (item : T) -> String {
    return "\(item)"
}

Infix modifiers are not allowed on func declarations, so you just declare a normal func:

infix operator *** {}
func ***(lhs: T, rhs: T) -> T {
    print((NSThread.currentThread().isMainThread ? "" : "[bg thread] "))
    println("\(rhs): \(lhs)")
    return lhs
}

Renaming. All CVarArg need to be replaced by CVarArgType. Sequence is now SequenceType, Generator is GeneratorType,  Mirror is MirrorType, LogicValue is BooleanType. A bunch of pointer types have been updated again as well. @auto_closure is now @autoclosure.  The .bridgeToObjectiveC() function now has a prefix hyphen: ._bridgeToObjectiveC().

Ranges. These have undergone big changes. These include

  • Ranges (discrete, increasing, consecutive values).  Non increasing ranges are now errors, e.g. 5…1
  • Intervals which check for containment, and must be Comparable. Used with switch statements and by the ~= operator
  • Strides (I think that’s the noun), which work with Strideable, Comparable values, and can advance with set, arbitrary distances.

Screen Shot 2014-08-04 at 12.11.14 PM

Documentation comments. The release notes specify that /** and /// are now fully supported. “Swift uses reStructuredText, an easy-to-read, modern lightweight markup language in documentation comments. ”

Important Array update. Don’t try adding items, add arrays. e.g. not foo += 5 but rather foo += [5].  Look for the “not identical to UInt8” error.

Init changes. The override and required keywords are no longer optional. If you’re subclassing, and there’s a required designated initializer, you must add it. Initializers with the same name as a parent must mention “override”. I’m updating a write-up for InformIT all about initializers right now to cover the changes.