9 ms·

A deep dive into Swift’s function builders

64 points by taksintikk 6y ago

setr 6y ago
I don't understand the necessity for BuildIf/BuildEither -- what could you possibly want to inject into a control-flow construct during initialization?
- rmrfrmrf 6y ago
  type of device (iPhone, iPad, etc)
- jumhyn 6y 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 6y 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.
    - jumhyn 6y ago
      That problem could have been resolved via type erasure (either via `AnyView`, or, if SwiftUI had been designed differently, by having the `body` property be of type `View` rather than `some View`). In fact, opaque types (a la `some View`) were motivated by SwiftUI so that the type information could be preserved to enable the necessary optimizations/animations, without requiring users/library authors to write out/expose the complex type signatures that can arise from even simple view hierarchies. Incidentally, if you use `AnyView` liberally you’ll likely see worse automatic animations and degraded performance [ETA: the “degraded performance” claim here appears to have been debunked—see the link below for more info!].
      - LeoNatan25 6y ago
        Despite what is claimed about AnyView, this has for the most part been proven wrong. AnyView is just as fast, if not faster. https://nalexn.github.io/anyview-vs-group/ https://nalexn.github.io/anyview-vs-group/ In fact, Apple themselves use AnyView internally for many of their controller presentations (such as sheets and pushed controllers).
        jumhyn 6y ago
        Great article! Glad to have that misconception cleared up.
- ridiculous_fish 6y 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/viewbuilder https://developer.apple.com/documentation/swiftui/viewbuilde...
- rudedogg 6y 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 6y 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 6y 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>.
jgauth 6y 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/9992cf3c11c2d5e0ea20bee98657d93902d5b174/proposals/XXXX-function-builders.md https://github.com/apple/swift-evolution/blob/9992cf3c11c2d5...
- wilg 6y 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/proposals/0289-function-builders.md https://github.com/apple/swift-evolution/blob/master/proposa...
LeoNatan25 6y 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.
- heavyset_go 6y ago
  > I’m getting old. I think you hit the nail on the head with this observation: > 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. For a while now, content's been created as a means to improve SEO, and it's really obvious when an article was written just so it contains the right mashup of keywords and that it's padded to just the right length.
- Benjammer 6y ago
  Two reasons for these shallow, high-level-walk-through type of articles that I've seen are to pad a resume or to pad a promotion packet.
  - LeoNatan25 6y ago
    Sure, this is a problem in general when companies require or “heavily encourage” its engineering to post “blogs”. And some developers are just not writers, or lack the skill to do proper articles. But, here, this is not the case; the author makes their living from this. With the former engineers, that’s excusable. Here, less so.
herodotus 6y 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 6y ago
What is the use case except swiftUI?

64 points by taksintikk 6y ago

setr 6y ago

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

rmrfrmrf 6y ago
type of device (iPhone, iPad, etc)
jumhyn 6y 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 6y 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.
  - jumhyn 6y ago
    That problem could have been resolved via type erasure (either via `AnyView`, or, if SwiftUI had been designed differently, by having the `body` property be of type `View` rather than `some View`). In fact, opaque types (a la `some View`) were motivated by SwiftUI so that the type information could be preserved to enable the necessary optimizations/animations, without requiring users/library authors to write out/expose the complex type signatures that can arise from even simple view hierarchies. Incidentally, if you use `AnyView` liberally you’ll likely see worse automatic animations and degraded performance [ETA: the “degraded performance” claim here appears to have been debunked—see the link below for more info!].
    - LeoNatan25 6y ago
      Despite what is claimed about AnyView, this has for the most part been proven wrong. AnyView is just as fast, if not faster. https://nalexn.github.io/anyview-vs-group/ https://nalexn.github.io/anyview-vs-group/ In fact, Apple themselves use AnyView internally for many of their controller presentations (such as sheets and pushed controllers).
      - jumhyn 6y ago
        Great article! Glad to have that misconception cleared up.
ridiculous_fish 6y 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/viewbuilder https://developer.apple.com/documentation/swiftui/viewbuilde...
rudedogg 6y 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 6y 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 6y 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>.

jgauth 6y 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/9992cf3c11c2d5e0ea20bee98657d93902d5b174/proposals/XXXX-function-builders.md https://github.com/apple/swift-evolution/blob/9992cf3c11c2d5...

wilg 6y 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/proposals/0289-function-builders.md https://github.com/apple/swift-evolution/blob/master/proposa...

LeoNatan25 6y 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.

heavyset_go 6y ago
> I’m getting old. I think you hit the nail on the head with this observation: > 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. For a while now, content's been created as a means to improve SEO, and it's really obvious when an article was written just so it contains the right mashup of keywords and that it's padded to just the right length.
Benjammer 6y ago
Two reasons for these shallow, high-level-walk-through type of articles that I've seen are to pad a resume or to pad a promotion packet.
- LeoNatan25 6y ago
  Sure, this is a problem in general when companies require or “heavily encourage” its engineering to post “blogs”. And some developers are just not writers, or lack the skill to do proper articles. But, here, this is not the case; the author makes their living from this. With the former engineers, that’s excusable. Here, less so.

herodotus 6y 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 6y ago

What is the use case except swiftUI?