Mike writes: How can I refactor this so I don’t use the same fail logic twice and won’t incur the costs of the expensive call unless needed? Is there an elegant one-line condition I can use to replace the nesting and redundancy? Using guard for early exit on myCondition is a no-go.

Here’s the code:

// Not ideal: Dupe fail logic
if !myCondition {
    if let myValue = getExpensiveComputationResult(){ 
        // Do my stuff 
    } else { 
        // Fail logic 
    }
} else {
    // Fail logic AGAIN
}

// Also not ideal: computation always processed regardless of myCondition
if let myValue = getExpensiveComputationResult() where !myCondition { 
    // Do my stuff 
} else { 
    // Fail logic 
}

A lot of developers new to Swift miss compound if statements. These consist of comma-delineated expressions which are evaluated in order. Compound if statements can include constant binding as in the following refactored code.

func expensiveCall() -> String? {
    print("EXPENSIVE!"); return "Expensive"
}

if !myAutoFailCondition, 
   let foo = expensiveCall() {
    print("Success, but expensive")
} else {
    print("Fail condition")
}

This example short-cuts if the “myAutoFailCondition” is true and the expensive function is never called. I encourage you to try this out in a playground.

The Swift if statement’s components can include a single expression that evaluates to true or false, an optional-binding condition, an availability condition, or a case condition. Always put the simple expression first or you’ll need to use where to separate it from the other kinds of checks. You’ll find the full grammar at the back of the Swift Programming Language book.

When was the last time you subclassed a class you created natively in Swift that wasn’t part of the Cocoa system? How often do you find yourself subclassing non-Cocoa types now that protocol extensions and regular ordinary extension extensions exist?

If your answer is somewhere between 0% and 5%, you’re fairly typical. Reference types are no longer tightly coupled with inheritance under Swift’s type system.

Pushing further, how often do you create classes and subclasses with the intention that they be furthered subclassed by API clients outside a particular module? (Assuming, of course, you’re not Apple, and you’re not writing views and controllers…)

Update: Matthew Johnson asked that I run this survey. Thank you for your participation.

When subclassing becomes the exception rather than the rule, is it time to consider making classes final by default? Or would it be better to seal modules as internal-by-default so public classes cannot be subclassed outside their module of origin.

Debate is currently raging on the Swift evolution list about how this might be approached, whether it should be done at all, and if classes could be designed to force calls to superclasses for overridden methods (“requires super call”).

John McCall writes:

Our current intent is that public subclassing and overriding will be locked down by default, but internal subclassing and overriding will not be.  I believe that this strikes the right balance, and moreover that it is consistent with the general language approach to code evolution, which is to promote “consequence-free” rapid development by:

(1) avoiding artificial bookkeeping obstacles while you’re hacking up the initial implementation of a module, but

(2) not letting that initial implementation make implicit source and binary compatibility promises to code outside of the module and

(3) providing good language tools for incrementally building those initial prototype interfaces into stronger internal abstractions.

All the hard limitations in the defaults are tied to the module boundary because we assume that it’s straightforward to fix any problems within the module if/when you decided you made a mistake earlier.

So, okay, a class is subclassable by default, and it wasn’t really designed for that, and now there are subclasses in the module which are causing problems.  As long as nobody’s changed the default (which they could have done carelessly in either case, but are much less likely to do if it’s only necessary to make an external subclass), all of those subclasses will still be within the module, and you still have free rein to correct that initial design mistake.

A thought from Joe Groff:

Robust subclassability requires conscious design just like all other aspects of API design.

Updated to add from Jordan Rose:

The interesting thing about this is that the “error of omission”—of failing to think about whether a class should be final—is worse than the alternative. Ignoring optimizations for a minute, a class that starts out ‘final’ can certainly become non-final later; it doesn’t change how the class is currently used.* For a lot of library evolution questions, this is the preferred answer: the default should be safe, and the designer of the class can choose to be more aggressive later.

Generic enhancements for Swift 3.0

I loved this post, which summarizes where things are and where things may yet go with respect to generics. I’ve posted before about several of these wish-lish items and this response by Doug Gregor to a post by Matthew Johnson covers not only what may be coming down the line (or not) but also why (or why not).

Bring me a Higher Love Kinded Type

There’s a long discussion about Higher Kinded Types such as monads, functors, and so forth ranging on-list. This isn’t something I’m particularly into and it reads to me as, “This stuff is cool” “Give some practical examples of how Swift coding would benefit.”  “But this stuff is cool.” I think I’m entirely missing the point.

Property Behaviors

Here’s a particularly cool proposal from Joe Groff that abstracts out common implementation patterns for annotating properties. This approach would allow the team to develop a library of common behaviors (vs hard-coding them into the compiler).

The behaviors could be expanded, tweaked, and used upon demand by annotating properties with parenthesized keywords. Not just lazy but lazy on steroids. I’m feeling very +1 on this and I learned the metasyntactic phrase “runcible“. Win.

Refactoring Code

public func imageFromVImageBuffer(var buffer: vImage_Buffer) -> UIImage? {

public func imageFromVImageBuffer(buffer: vImage_Buffer) -> UIImage? {
    var buffer = buffer

defer {index = index.successor()}
return (index, self[index])