Many Cocoa and Cocoa Touch calls are boilerplate. They use common argument values that are the same with nearly every call. Why not take advantage of Swift’s default system instead? We’d like to simplify calls like this:

dismissViewControllerAnimated(flag: true, completion: nil)

to calls like this:

dismiss()

Default Values

SE-0005 introduced a number of ways in which ObjC APIs will gain default values through automatic translation. Under this accepted proposal, any method that matches certain patterns will now provide default values.

Daniel Steinberg and I love this defaulting behavior and approached the Swift Evolution list to see whether we could expand defaults for Cocoa and Cocoa Touch APIs even further. David Abrahams replied that we should best proceed by putting together specific requests and file them as radars for the UIKit/AppKit teams, who would then presumably provide extensions that pass the default values.

Here’s our preliminary list of updates we’d like to see. We’re requesting community input to help us expand this list so when we approach Apple with our bug reports, we’ve already thought through and prioritized the kinds of changes we’re invested in.

I’ve put up a gist and hope that anyone who’s interested in contributing will ping us by comment, twitter, or email.

Controls

We feel that UIControl states should always default to .Normal. So, for example, you’d call button.setTitle("Hello") vs button.setTitle("Hello", forState: .Normal). Since these are just defaults, you can always override the state (for example, when using highlights) with the fully specified argument.

Control actions are also fairly predictable. Buttons normally trigger with .TouchUpInside and sliders and switches with .ValueChanged.  By providing defaults, the code simplifies except in those cases where the author intentionally means to use a non-standard pattern.

Core Graphics

We want to default all CG constructors to 0.0, namely x, y, dX, dY, width, and height. You would not be limited, of course, from specifying all elements but at the same time, you could create origin-based rectangles with just CGRect(.width: 200, .height: 100).

Views

We’d like to default animated to true for most UIKit calls. We’re not saying use super.viewWillAppear() — go ahead pass the animated argument that was passed to you. We’re saying instead in calls like dismissViewControllerAnimated, that the most common UIKit (and probably Cocoa) scenario uses animation. Adding a default here simplifies the calls with an understood “common practices” approach.

Auto Layout

We have a rather mixed bag with NSLayoutConstraint. Pretty much we and everyone we’ve talked to agree that a default multiplier of 1.0 and constant of 0.0 are sensible.

However, my initial suggestion that the default relation (relatedBy:, .Equal), second item (toItem:, nil), and second attribute (attribute:, .NotAnAttribute) raised the question of defaults hiding parameters and reducing readability, especially since it’s far more common to layout multiple views with respect to each other than single view attributes (NSLayoutConstraint(item: view, attribute: .Width, constant: 400.0)). We’re less wedded to the second half of this default pattern.

Other Common Patterns

Apple’s UIKit Framework Reference offers a further overview of UIKit classes, additions, functions, constants, and data types. I’m sure there’s an equivalent for Cocoa as well somewhere in the reference library. If you want to pitch in, what we’re looking for are examples of common API calls that use predominantly default API values that the developer must currently enter at each call site, and whose defaults are not already subsumed by SE-0005.

If you have any examples of these, just ping either of us and we’ll update the gist with your feedback. Our goal is to try to grow this set and have it peer reviewed before we start submitting radars to Apple.

Thanks in advance!