A deep dive into Swift’s function builders
swiftbysundell.com
A deep dive into Swift’s function builders
1–10 of 39 posts
Re: A deep dive into Swift’s function builders
#2I don't understand the necessity for BuildIf/BuildEither -- what could you possibly want to inject into a control-flow construct during initialization?
Re: A deep dive into Swift’s function builders
#3Great 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...
Re: A deep dive into Swift’s function builders
#4I don't understand the necessity for BuildIf/BuildEither -- what could you possibly want to inject into a control-flow construct during initialization?
type of device (iPhone, iPad, etc)
Re: A deep dive into Swift’s function builders
#5I don't understand the necessity for BuildIf/BuildEither -- what could you possibly want to inject into a control-flow construct during initialization?
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")
}
1. Text("True")
2. Text("False")
1. ConditionalContent(first: Text("True"))
2. ConditionalContent(second: Text("False"))
Re: A deep dive into Swift’s function builders
#6I don't understand the necessity for BuildIf/BuildEither -- what could you possibly want to inject into a control-flow construct during initialization?
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>`. 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...
Re: A deep dive into Swift’s function builders
#7I don't understand the necessity for BuildIf/BuildEither -- what could you possibly want to inject into a control-flow construct during initialization?
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.
Re: A deep dive into Swift’s function builders
#8I don't understand the necessity for BuildIf/BuildEither -- what could you possibly want to inject into a control-flow construct during initialization?
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 i…
It's more fundamental than that. Consider:
var body : some View {
if something {
return Image("hi")
} else {
return Text("hi")
}
}
In order to give the return value a type, the if statement has to be encoded in the type system itself.
Re: A deep dive into Swift’s function builders
#9Great 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...
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...
Re: A deep dive into Swift’s function builders
#10I 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.