A deep dive into Swift’s function builders

A deep dive into Swift’s function builders(swiftbysundell.com)

64 points by taksintikk 5 years ago | 38 comments

jgauth 5 years ago |

Great article. As someone new to Swift and SwiftUI, the lack of official documentation around these function builders is frustrating. The best I could find was a draft proposal [1].

[1]: https://github.com/apple/swift-evolution/blob/9992cf3c11c2d5...

wilg 5 years ago | |

Well I think that's because they aren't yet an official part of the language until that proposal is accepted, and Apple is shipping them as a custom extension to Swift that they hope to remove at some point.

Edit: Also the current version of the proposal is here: https://github.com/apple/swift-evolution/blob/master/proposa...

setr 5 years ago |

I don't understand the necessity for BuildIf/BuildEither -- what could you possibly want to inject into a control-flow construct during initialization?

jumhyn 5 years ago | |

From what I understand, SwiftUI uses this so that each "snapshot" of the View tree generated by the app can be intelligently diffed against future snapshots. This helps make rendering more efficient, as well as with things like animations. Consider a simple view like:

  var body: some View {
    if someStateBool {
      Text("True")
    } else {
      Text("False")
  }

Suppose that initially, `someStateBool ` evaluates to `true`, and then is updated to `false` (triggering an update. If the control flow were "flattened" (i.e., without `buildEither`), the two snapshots would look like:

  1. Text("True")
  2. Text("False")

The algorithm wouldn't be able to tell the difference between "same view with different string" and "different view entirely". With `buildEither`, the snapshots end up looking more like:

  1. ConditionalContent(first: Text("True"))
  2. ConditionalContent(second: Text("False"))

Now, the update algorithm can determine that the entire view was swapped out for another on the update, rather than just changing the text.

ridiculous_fish 5 years ago | | |

It's more fundamental than that. Consider:

    var body : some View {
       if something {
          return Image("hi")
       } else {
         return Text("hi")
       }
    }

this function won't even compile because Swift infers different types for the returns (Image vs Text).

In order to give the return value a type, the if statement has to be encoded in the type system itself.

ridiculous_fish 5 years ago | |

A SwiftUI view is a function which returns a strongly-typed value. Strongly-typed here is stronger than you may be familiar with, it's like `View<HStack<Button, Slider, TextField>>`. The whole view hierarchy has some type.

You don't have to write these types because Swift can infer them. But when you write a view, you're really also stitching together a type. This explains some of the weird-feeling limitations, like no more than 10 subviews - since every possible count needs its own separate generic function! [1]

Anyways the control flow constructs are needed so it can be encoded in the type. You need a way to say "I can be this type, or that type" at the type level - that's what _ConditionalContent encodes. Not a SwiftUI expert but that's my understanding.

1: https://developer.apple.com/documentation/swiftui/viewbuilde...

rudedogg 5 years ago | |

Not sure if I'm missing something, but under the "Conditionals" heading there is an example.

I've been writing a lot of SwiftUI code since it came out - and a common use is like that example. Imagine a settings UI where you want to only show an advanced option if a switch/checkbox is toggled.

setr 5 years ago | | |

The example of...

    static func buildIf(_ value: SettingsConvertible?) -> SettingsConvertible {
        value ?? []
    }

and

    static func buildEither(first: SettingsConvertible) -> SettingsConvertible {
        first
    }

    static func buildEither(second: SettingsConvertible) -> SettingsConvertible {
        second
    }

These just return their values -- the only one of note is that buildIf returns the empty array by default, but otherwise this is just defining an if statement to be an if statement.

It gives you however to make an if statement do something other than being an if statement, and that seems... bad.

You could for example define it as

    static func buildEither(first: SettingsConvertible) -> SettingsConvertible {
        []
    }
    static func buildEither(second: SettingsConvertible) -> SettingsConvertible {
        []
    }

dwaite 5 years ago | |

In other languages, the builder pattern usually consists of just methods on a builder object that manipulate internal state until you 'build' an instance. Function builders on the other hand support building of a strong type.

The builder can convert expressions into components that are then assembled into results. Some applications want to be able to represent the result as a strong generic type.

As an example of this, imagine

  if let releaseName = releaseName {
     Div("Release \(releaseName)")
  else {
     Blink("Prerelease")
  }

might be captured by such a builder as an Either<Div, Blink>.

rmrfrmrf 5 years ago | |

type of device (iPhone, iPad, etc)

herodotus 5 years ago |

I enjoy articles like this. And I am spending a fair amount of my retirement time writing Swift. In fact I have written a reasonably complex MacOS App in Swift, and it works well. (For the 15 or so years I worked at Apple everything I wrote was in Objective-C or C). But Swift has what one of my friends calls "a high surface area". In spite of using Swift almost daily, I have to say that if someone asked me "Do you know how to program in Swift" I would have to honestly answer "No."

carlhung 5 years ago |

What is the use case except swiftUI?

LeoNatan25 5 years ago |

I must have a different idea of what “deep dive” means; this is simply going through the (relatively simple) motions of implementing a builder. “Deep dive”, to me, would look at how the compiler translates statements using these builders, for example, or reverse-engineering Apple’s builders for juicy information.

I’ve recently forayed into SwiftUI to see what all the fuss was. I have to say, I really feel for people just now starting to learn app development. Older Cocoa and iOS developers probably remember what actual in-depth articles look like, what “deep dives” actually are, etc. Instead, what we have is a culture of very shallow and information-light “articles”, that seems to me more like SEO bot posts trolling for clicks, rather than written for developers, by developers. And it’s not like the Sundells and Hudsons, but also NSHipster, CocoaWithLove, etc., which were traditionally where high-quality and information-rich content would come from in the past. Likewise with conferences, whereas in the past they’d invite developers to “deep dive” into and interesting development or debugging session, now they’ve devolved, for the most part, into these shallow, byte-sized “Swift” nonsenses. As if the language somehow defines the identity of the developers, and apps magically become much better as virtue of the language used, rather than the system frameworks.

I’m getting old.

static func buildEither(first: SettingsConvertible) -> SettingsConvertible { first } static func buildEither(second: SettingsConvertible) -> SettingsConvertible { second }