I finally figured out the Swift 1.2 “if-let” construct

In the old days, pre-Swift-1.2, you have to nest if-let statements

if let foo = who() {
    if let goo = what() {
        ...

This was extended in Swift 1.2, and the best resource for understanding the changes is in the Xcode 6.3 notes (search for “Swift Language Enhancements”).

The usage of this new feature is not immediately obvious – at least not to me. I had a somewhat hard time figuring out how I was going to style these, and in the end I started off with this:

if  let foo = who(), // "if-tab-let"
    let goo = what() // tab then "let"
    ...
{

Then I started adding where clauses:

if  let foo = who() where foo > 1,
    let goo = what() where goo > 2,
    ...
{

Great! That worked. Then I tried adding standalone logic tests

if  let foo = who() where foo > 1,
    let goo = what() where goo > 2,
    counter > 5 // NO GO
{

On a further read of the Xcode release notes, I find that I’m allows one clause logic statement as long as its the first clause:

if  counter > 5,
    let foo = who() where foo > 1,
    let goo = what() where goo > 2
{

A short while ago, I tripped on an NSHipster blog where he deleted all but the first let, and then used a different indention format, which I really liked:

if let // one space between if and let
    foo = who(), // a 4 space tab stop
    goo = what(),
    ...
{

But when I started adding where clauses, the compiler complained:


if let // one space between if and let
    foo = who() where foo > 1,  //  2, // <- PROBLEM
    ...
{

It turns out if you read the notes closely, that the where clause applies to all optional unwrap statements back to the preceding let statement. So if you want multiple where clauses. Ugh. So I can do the formatting using the NSHipster style, but I’ll have to space the additional lets.


if let
    name = name(),
    foo = who() where foo > 1 && !name.isEmpty,
   let goo = what() where goo > 2, // 3 spaces (ugh)
   ...
{

I can even add back my initial logic clause:


if counter > 5,
   let
    name = name(),
    foo = who() where foo > 1 && !name.isEmpty,
   let 
    goo = what() where goo > 2,
...
{

The whole topic of code formatting is a moving target, especially since Apple keeps enhancing the language.

Hope you find this helpful!

Swift Goodies: Using Enums for View/Segment Identification

One technique I used in Objective C to make my code clearer was using enums to map my ‘view with tag’ or ‘segment index’ to something besides a number.

That is, given a table view cell with 4 ‘tagged’ views, instead of writing:

switch (sender.tag) {
case 1:
...

I’d use an anonymous enum:

static enum { 
    NameTextField=1, EnableSwitch
};

switch(sender.tag) {
case NameTextField:
    ...
    break;
case EnableSwitch:
    ...
    break;
//default: // Not needed if you added a case for each enum value
}

In Swift, you can do the same, and even better, your enums can be namespaced (meaning, you can use ‘Email’ in more than one)

private enum Segments: Int {
    case Name = 1, Email
}

@IBAction segmentedAction(sender: UISegmentedControl) {
let selectedSegment = Segments(rawValue: sender.selectedSegmentIndex)!
switch selectedSegment {
case .Name:
    ...
case .Email:
    ...
//default: () // Not needed if you add a case for each enum value
}

When I go back and look at old code, these strings greatly improve the speed at which you can understand what the code is suppose to do.

Swift Goodies: Ideas for Cascading ‘if’ Clauses

Swift 1.2 has brought the ability to cascade let and logic within the scope of one if statement – this is huge and will be widely used. However, what’s missing is some concept of how to style them.

In much of the Apple code, one sees them cascaded on one line, then after 80 characters or so a continuation on the second line:

if let foo = x as? String, a = b(), let c = y as Int where c > blahBlah, more, and more, and more {

with the beginning ‘{‘ brace at the end.

Personally, I find this hard to read, and its hard to visually find the beginning brace on these multi-line statements.

I thought about:

if
    let foo = x as? String,
    let c = y as Int where c > blahBlah,
    more,
    and more
{


which is easy to type - hit the tab key after typing 'if' and then Xcode autoindents the rest for you. This is similar to a style I often used in large 'C' (or Objective C) if statements.

However, there would seem to be reluctance to wasting a whole line with 'if', so what I'm doing is typing 'if' followed by a tab followed by the first clause:

if  let foo = x as? String,
    let c = y as Int where c > blahBlah,
    more,
    and more
{


I'm fairly happy with this, and when I need to convert a single clause if to have multiple clauses, I then add a the tap in front of the first clause, and a new line + backspace in front of the '{' char.

You may not like either of the above styles, but its worth thinking about what style you do like, and then consistently apply it as you write your code.

Swift 1.2 Nullability is Improving My Objective C Code

Swift 1.2 introduced ‘nullability’, a feature whereby you can annotate your Objective C headers and declare method parameters, propterties, and returned objects as ‘possibly nil’ or ‘never nil’ (a third edge case will be undiscussed here).

I support a library that might be used with earlier versions of Swift and/or Xcode, so need to use the annotation in a backward compatible fashion.

What I discovered is that the ‘pragma’s don’t generate any warnings so it would appear you can just add those:

#pragma clang assume_nonnull begin // start of interface
// interface
#pragma clang assume_nonnull end // end of interface

However, the ‘nullable’ and ‘non-nullable’ annotations cause older Xcodes errors, and files won’t compile. The workaround is to use this construct:

#if ! __has_feature(nullability)
#define nullable
#define nonnull
#endif

So the above is one way to deal with the mechanics of using this new feature. But what of the actual feature itself?

When I sat down and looked at my code, I realized that I was often returning nil for an array that could have returned objects, but no objects met the criteria. After all, we all know that ‘[array count]’ return 0 for a nil array and for an actual array with no objects, right?

But really, this is sloppy coding. In one case, I have a protocol method that can return an array of objects and an optional NSError – if success always return an array and no error, and if failure then no array and an error.

This now maps much better into Swift – I can use ‘if let’ to test for an array, if there process as a successful return, and in no array then use ‘!’ on the NSError as it must be there.

I spent an hour or two really thinking about what I was doing in the public facing interfaces, and tweaking them to be more Swift friendly, which also meant they are now more internally consistent and don’t seem so haphazard.

First Swift Style Guide

I’ve spent a good deal of time reading the Swift manual, to learn this critical new piece of Apple Technology. All the gray-haired old timers are learning it, spending at least as much time as fresh-outs for sure. We know only too well how fast and relentless Apple pushes its technology, and those who dally will be left in the dust.

So many have asked “What constitutes good Swift coding practices?”, the stock answer being “No one knows yet”. Well, one good step forward is to more or less agree on a coding style (even thought Apple’s sample code is all over the map). It seems that Ray Wenderlich posted a Swift Style Guide  around the start of August, and I just read it.

Mostly I agree with it, and remember that this style guide is for code posted on its site, so in some sense must be more readable than code we write for ourselves. Not sure about making my tab stops 2 spaces, but I can see the logic in it – the big problem for real coders is going to be switching back and forth between older ObjC code and Swift, so different tab stops is a huge PITA.

I finally figured out weakSelf and strongSelf

One problem with using blocks and asynchronous dispatch is that you can get into a retain cycle – the block can retain ‘self’, sometimes in mysterious ways. For instance, if you reference an ivar directly, what appears in the code is ‘theIvar’, the compiler generates ‘self->theIvar’. Thus, ‘self’, as a strong variable, is retained, and the queue retains the block, and the object retains the queue.

Apple recommends first assigning ‘self’ into a weak automatic variable, then referencing that in a block (see 1). Since the block captures the variable along with its decorators (i.e. weak qualifier), there is no strong reference to ‘self’, and the object can get dealloced, and at that moment the weak captured variable turns to nil.

__weak __typeof__(self) weakSelf = self;
dispatch_group_async(_operationsGroup, _operationsQueue, ^
{
[weakSelf doSomething];
} );

Thinking about this, it occurred to me that ‘weakSelf’ might turn to nil in the middle of ‘doSomething’, but after a few posts on the xcode list, I was given a reference to a clang document that explicitly states that any object within an expression is retained for the complete expression, and only released thereafter (see 2). Whew!

But how about:

__weak __typeof__(self) weakSelf = self;
dispatch_group_async(_operationsGroup, _operationsQueue, ^
{
[weakSelf doSomething];
[weakSelf doSomethingElse];
} );

Well, in this case, its possible for ‘weakSelf’ to be non-nil for the first method, but not for the second. Hmmm – the above is a simple example, most real code would get much more complex with other usages of ‘weakSelf’.

Apple calls this second example ‘non-trivial’ (see 1), and does what first seems like a bizarre set of steps: first create the ‘weakSelf’ object, then assign that to a ‘strongSelf’:

__weak __typeof__(self) weakSelf = self;
dispatch_group_async(_operationsGroup, _operationsQueue, ^
{
__typeof__(self) strongSelf = weakSelf;
[strongSelf doSomething];
[strongSelf doSomethingElse];
} );

or in Swift:

dispatch_async(dispatch_get_main_queue()) { [weak self] in
if let strongSelf = self {
//…
}
}
// See “Resolving Strong Reference Cycles for Closures” in The Swift Programming Language

I looked and looked at this trying to reason it out (guess I’m just slow). Finally, the light bulb lit, and I figured it out! When the block runs, it’s only captured ‘weakSelf’. At the instant the block starts up, ‘weakSelf’ is either ‘self’, or it’s nil. Your code (as Apple’s example does) can test to see if ‘strongSelf’ is set, and if so you can use ‘strongSelf->theIvar’ or the more normal ‘strongSelf.someProperty’ (the latter works fine with nil messaging, the former will crash if ‘strongSelf’ is nil).

If ‘weakSelf’ is equal to ‘self’, then ‘strongSelf’ retains it, and it stays retained until the block returns, when its released. It’s all or nothing.

I felt really good finally getting this, and its making my coding of blocks much easier.

NOTE:

If you’re puzzled by the use of __typeof__(self), it’s a non-standard clang macro that turns into the class of the parenthesized object, and was taken from GCC. The nice thing about using it is that you can make this line a Code Snippet (mine is called ‘WeakSelf’), and you don’t have to continually adjust the class type.

1) “Programming With ARC Release Notes, search for “For non-trivial cycles, however, you should use”

2) http://clang.llvm.org/docs/AutomaticReferenceCounting.html :

For __weak objects, the current pointee is retained and then released at the end of the current full-expression. This must execute atomically with respect to assignments and to the final release of the pointee.