While I don't yet have great confidence in my mental model of SwiftUI's type system, my understanding is that the DSL builders exist for more reasons than just

While I don't yet have great confidence in my mental model of SwiftUI's type system, my understanding is that the DSL builders exist for more reasons than just to eliminate commas. The new Function Builder and `some` return type features of Swift allow you to return a complex, nested type describing not just that it's a View but rather also all the structure within. This means that at runtime you can have a (non-erased!) type describing the contents of your `var body` like this: Button<Group<_ConditionalContent<Text, Image>>> This particular body displays a Text if a state boolean is true, and an image if not. Super interesting - and having types this descriptive can potentially enable a host of interesting features and optimizations. For example, across evaluations of your UI SwiftUI needs to track the identity (and location in your view graph) of all of your views, in order to keep their state, bindings, and other stuff that needs to remain consistent across time. The position if your view in a type hierarchy is the default way SwiftUI does so. This starts to blur the line between code and the type system, which I think the Functional Programming folks have been exploring for years. One more nitpick: the use of View Modifiers on children noticed by parents (like the `navigationBarTitle` example he uses (as discussed in the "Child Privacy Invasion" section), is to allow for children to specify metadata that the parent might care about. This is actually pretty nice, because then you can nicely compose together the various parts of your app without having to spread around the configuration for your tab bars and such (which is a bit messy in UIKit). edit: formatting. I always trip up with it on HN due to the lack of a Preview feature.