Read on Twitter
There& #39;s always something you want to talk about but can& #39;t fit in. This year, it& #39;s what "simplifying…irrelevant parts of some SwiftUI types" in the first example skipped over.
(You *don& #39;t* need to know this—that& #39;s why I left it out!—but it& #39;s interesting.) https://developer.apple.com/videos/play/wwdc2021/10253/">https://developer.apple.com/videos/pl...
(You *don& #39;t* need to know this—that& #39;s why I left it out!—but it& #39;s interesting.) https://developer.apple.com/videos/play/wwdc2021/10253/">https://developer.apple.com/videos/pl...
"Demystify SwiftUI" touches on how the presence of an "if" statement in a view& #39;s body becomes part of its result type, and how SwiftUI relies on that to determine a view& #39;s structural identity.
How does that happen?
https://developer.apple.com/videos/play/wwdc2021/10022/">https://developer.apple.com/videos/pl...
How does that happen?
https://developer.apple.com/videos/play/wwdc2021/10022/">https://developer.apple.com/videos/pl...
You can see the declaration for the real ViewBuilder by searching for "struct ViewBuilder" and "extension ViewBuilder" in the file this opens:
$ xed `xcrun --show-sdk-path`/System/Library/Frameworks/SwiftUI.framework/Modules/SwiftUI.swiftmodule/x86_64-apple-macos.swiftinterface
$ xed `xcrun --show-sdk-path`/System/Library/Frameworks/SwiftUI.framework/Modules/SwiftUI.swiftmodule/x86_64-apple-macos.swiftinterface
(Side note: This file is not normal Swift code and it& #39;s full of weird, specialized syntax. If you see something with ` @_` at the beginning of it, you probably shouldn& #39;t use it. Half of it doesn& #39;t work in normal source code and the other half could stop working at any moment.)
If you look around, you& #39;ll eventually see that ViewBuilder has buildEither(first:) and buildEither(second:) methods. But unlike the ones I showed you in my session, they& #39;re generic and they have these signatures:
And there it is, in the result types: "_ConditionalContent<TrueContent, FalseContent>". In the "Demystify SwiftUI" slide, `TrueContent == AdoptionDirectory` and `FalseContent == DogList`, so you get the type on that slide.
So why didn& #39;t I teach you about ViewBuilder& #39;s generics? Well, two reasons.
One: Very few result builders need to do this. SwiftUI is doing something really unusual—most result builders can either use a fixed set of types or use type erasure, so they don& #39;t need this approach.
One: Very few result builders need to do this. SwiftUI is doing something really unusual—most result builders can either use a fixed set of types or use type erasure, so they don& #39;t need this approach.
Two: Some of the techniques you need are pretty inelegant. In particular, `buildBlock` needs to allow parameters to have different types, but a generic parameter that& #39;s variadic doesn& #39;t do that. So SwiftUI overloads "buildBlock" for different statement counts:
But again, this is a weird quirk of SwiftUI& #39;s design, not something most result builders should do. If you write a result builder, you should almost certainly use one variadic "buildBlock" method and, if necessary, erase the types of individual statements with "buildExpression".
If I had tried to explain all of this the very first time I talked about how result builders work, you all would have been very confused. So instead I simplified it so you could learn from an example that& #39;s closer to how you& #39;d usually write a result builder:
SwiftUI& #39;s way is mostly a curiosity, but I hope you enjoyed learning about it!
