The following code is thoroughly legal in Swift:

You can also initialize a Double with an Int because Double is an IntegerLiteralConvertible.

let myDouble: Double = 1

This kind of thing gets on my style nerves. If you were theoretically writing an opinionated guide to Swift Style, what kind of advice would you give here? What practice offers the greatest advantage when reading coding intent?

My first go at it is this: In any situation where you have the ability to accurately express the intended type of a constant value, prefer the typed variant over one that can be inferred or cast.

Late last week, I was helping a fairly new Swift developer with his code that initially looked like this:

func generateContact(withAddress: Bool, withEmail: Bool, withPhone: Bool) -> Customer // not my code

It occurred to me that multiple Boolean flags would be much better represented as ad-hoc option sets. So I set out to discover how often this pattern showed up in code. I asked for examples on the Swift Evolution list, headed over to both Github and to searchcode.com, trying to track down examples and determine whether this was a relatively common pattern in Swift.

I pulled down all the Apple code, cloned a lot of the top Swift Github repos, and performed searches (the best I could, all things considered) through gists to test whether multiple Bool arguments was a common use that could be improved.

What I found was this:

• In both Apple and “Top Swift” repos, I found few circumstances where multiple boolean flags were used at all.
• Two flags was the most common multiplicity. Three flags were rare. I don’t remember finding any with four or more.
• Multiple booleans were primarily used initializers, with a few instances from graphics code for things like stroke and fill.

convenience init?(before: Bool, during: Bool) {
convenience init?(before: Bool, during: Bool, after: Bool) {
func nested_if_merge_noret(x: Int, y: Bool, z: Bool) {
func render(fill: Bool, stroke: Bool) {
public init(hasStroke: Bool, hasFill: Bool, evenOdd: Bool = false) {
public init(x0: CGFloat, y0: CGFloat, rx: CGFloat, ry: CGFloat, angle: CGFloat, largeArcFlag: Bool, sweepFlag: Bool, x: CGFloat, y: CGFloat) {

convenience init?(flags: @options(before, during, after)) {

let foo = T.init(flags: [.before, .after])

Since I started programming in Swift, I moved to the “Ash Rule” of left-hugging colons in all uses except ternary, up to and including dictionary references,  protocols, etc. Here’s what that looks like in use:

let x: [String: String] = ["key": "value"]
let y = foo(param1: value1, param2: value2)
func bar<T: Hashable>(a: T) -> Void {}

It felt weird for a while but I’ve now grown used to it. This approach is consistent, prioritizes the role of the left item, and is (in my opinion) quite readable. Compare and contrast with my prior style, which I call the “Full Space Monty” approach:

let x : [String : String] = ["key" : "value"]
let y = foo(param1 : value1, param2 : value2)
func bar<T : Hashable>(a : T) -> Void {}

The Ash Rule puts me in step with about half of Apple source code and out of step with the rest. Colon magnetism tends to vary by both group and individual producer. I mention this because Dave Abrahams clarified StdLib style on the Swift Evolution list today:

• Full monty spaces for declarations and extensions
• Left magnetism for providing values

Here’s an example I grabbed from Evolution that showcases some fascinating code styling choices. Focusing only on colons however, here’s what there is:

public func contains(value: Bound) -> Bool 
public var description: String 

protocol _ClosedRange : _RangeProtocol {}
public struct ClosedRangeIndex<
  Bound : Comparable where Bound : _Strideable
> : Comparable {

I’m going to assume the bolded use in the following snippet is an oversight:

extension _ClosedRange {
 @inline(__always)
 public init<
   Other: _ClosedRange where Other.Bound == Bound
 >(_ other: Other) {
     self.init(
     _uncheckedBounds: (lower: other.lowerBound, upper: other.upperBound)
     )
   }
...
}

While this next one is intentional since the ClosedRangeIndex is typing the lhs and rhs arguments:

public func == <B>(lhs: ClosedRangeIndex<B>, rhs: ClosedRangeIndex<B>) -> Bool {

This style isn’t universal. Apple Developer Publications uses Mike Ash colons.

When it comes to colon style, I don’t think there are right or wrong answers but I do think that whatever style you do choose naturally breaks down into the following categories:

• label declarations func f(x: T)
• collection lookups [key: value] (Empty case is universally [:] not [: ].)
• cases case A, B:
• inheritance class x: Y
• conformance <T: A>, <T: protocol<A, B>> {}
• attribute  @attribute(key: value), e.g. @available(*, unavailable, renamed: “MyRenamed”)
• ternary A ? B : C

I think there’s a general unity of opinion when it comes to case and ternary. No space for cases; always spaces for ternary. There’s little controversy or variation as far as I can tell.

The newly attribute style is up for grabs but I think it will follow label declarations in using left-magnetic colons.

The Swift Programming Language uses left-magnetic colons for dictionaries:

although the grammar does not: (Jordan Rose: ” Not sure I’d count the grammar as any particular evidence. Traditionally, grammars put spaces around everything.”)

Its property, constant, and variable declarations are pretty much uniformly left-magnetic:

I didn’t find any inheritance that wasn’t left-magnetic:

So what’s your house style and how did you come to it?

Another little tweak in response to a Swift Evolution thread:

public extension Dictionary {
    public subscript(key: Key, default fallback: Value) -> Value {
        return self[key] ?? fallback
    }
}

Always returns an unwrapped value. You supply a fallback.

values[self, default: "?"]

If you omit the external default keyword, it looks like this instead:

values[self, "?"]

Idea brought up on Swift Evolution by Zsolt Szatmari:

The only thing I am really missing right now from Swift is described as following. This works in some other languages, e.g.  F#, Kotlin, and Haskell.

let john = {firstName="John"; lastName="Doe"}

let alice = {john with FirstName="Alice"}

Current way to do this in Swift is:

let john = (firstName:"John", lastName:"Doe")
var alice = john
alice.firstName = "Alice"

This might seem to be a nuance, but it’s more cumbersome (especially if one wants to do this frequently), and we are left with a var at the end.  Also, this idea rhymes with the current direction of removing var arguments from functions.

Unless I am overlooking something major here (wouldn’t be the first time), there’s actually a pretty easy way to do this in existing Swift:

struct Person {
    var firstName, lastName: String
}

let john = Person(firstName: "John", lastName: "Doe")

func modify(item: T, update: (inout T) -> Void) -> T {
    var this = item
    update(&this)
    return this
}

let carol: Person = modify(john) { $0.firstName = "Carol" }

print(carol) // Person(firstName: "Carol", lastName: "Doe")

The `modify()` function makes a new copy, applies any changes, and returns the new instance. Swift’s type inference system ensures that the  associated closure can access instance members.