Function builders

[griotspeak (TJ Usiyan)]

On top of what John said, my point is that this feature will only be made better by the addition of Variadic Generics. Nothing will be lost. The features are related in use but orthogonal in term of implementation.

[anandabits (Matthew Johnson)]

@John_McCall

I think people are getting hung up about variadic generics because SwiftUI specifically would benefit from them, but most users don't need them; normal variadic functions are fine if you don't need type propagation.

Right. An arbitrary limitation of 10 subview expressions with a very unhelpful error message when you exceed that is going to be confusing to a huge number of people. That's why it's important to raise the priority of variadic generics. It would be really good if it was possible to get it in before SwiftUI is released.

[idrougge (Iggy Drougge)]

As a language-level feature, this feels more like a hack than a natural road ahead for Swift. Something like Kotlin's approach to DSLs should be considered as an alternative in the pitch.

[Paul_Cantrell]

I like the word “builder” in there somewhere. It communicates something useful.

“Result builder” isn’t bad, although the word “result” isn’t doing much work. If a result is just “something that happened because the code executed” or “something other code uses,” what would a builder build other than a result?

I kind of like just “builder” by itself. It works when I try it in context — “a builder collects unused expression results;” “builder syntax does not yet support for loops;” “a SwiftUI View builder” — although the confusion with the more general GoF Builder Pattern seems problematic.

How is this different from other instances of the builder pattern, then? Sugar and conciseness? Thus “concise builder?” “Embedded builder?”

The distinguishing feature of this proposal as an approach to eDSLs, the thing that differentiates it from both yielding coroutines and the common Kotlin & Ruby approach of rebinding self in the closure body, is that instead of letting the DSL code execute freely and opaquely pass values back to the caller, this proposal exposes the whole control flow of the DSL closure to the caller. (This feature of the proposal is intriguing, and took a while to sink in. Aside: does SwiftUI use this knowledge of how many conditional branches are possible to automatically handle table cell reuse?) I’ve fished around a bit for a name that captures this, but the results aren’t exactly satisfying: “syntax decorator,” “control flow delegate,” “control-flow-aware builder.”

[yesleon (Li-Heng Hsu)]

Builders can be structs and other constructs though. Aside from builder functions, I think functional builders is another good option.

[tikitu (Tikitu de Jager)]

Do I have it right that there's no convenient way to extract part of a DSL expression-sequence for reuse? I'm thinking particularly of an if statement: if I wanted to pull that out to a reusable function, what would that look like?

(Disclaimer: I didn't get a chance to play with SwiftUI yet, which would probably answer this question fairly quickly.)

[kansaichris (Chris Frederick)]

This is a very interesting addition to the Swift language, but I do agree with many of the concerns voiced here that there are still some rough edges to be worked out.

@John_McCall

I think people are getting hung up about variadic generics because SwiftUI specifically would benefit from them, but most users don't need them; normal variadic functions are fine if you don't need type propagation.

With all due respect, this feels a bit contradictory to me. As far as I understand it, the whole raison d'être of this proposal—and the rejection of other alternatives like receiver closures—is SwiftUI's need for type propagation, which most users don't need, so by your logic, we shouldn't get hung up about type propagation, either, because most users don't need it.

@Paul_Cantrell

How is this different from other instances of the builder pattern, then? Sugar and conciseness? Thus “concise builder?” “Embedded builder?”

Or maybe just "DSL builder"?

@tikitu

Do I have it right that there's no convenient way to extract part of a DSL expression-sequence for reuse? I'm thinking particularly of an if statement: if I wanted to pull that out to a reusable function, what would that look like?

I think you could extract an if statement into a function that returns an optional value for use within a DSL builder block. For example, take this sample code from the proposal:

div {
  if useChapterTitles {
    h1(chapter + "1. Loomings.")
  }
  p {
    "Call me Ishmael. Some years ago"
  }
  p {
    "There is now your insular city"
  }
}

The h1(_:) function above has the following signature:

func h1(_ text: String) -> HTMLNode { ... }

However, I think you should be able to add a new function that returns an optional, instead:

func h1(_ text: String, isVisible: Bool) -> HTMLNode? {
  return isVisible ? h1(chapter + "1. Loomings.") : nil
}

You could then replace the if statement in the DSL block as follows:

div {
  h1(chapter + "1. Loomings.", isVisible: useChapterTitles)
  p {
    "Call me Ishmael. Some years ago"
  }
  p {
    "There is now your insular city"
  }
}

If I understand the proposal correctly, the result of h1(_:isVisible:) will be included in the div if useChapterTitles is true and it will simply be omitted if useChapterTitles is false.

[Jakub_Suder]

I've just noticed another limitation of builders - apparently you can't use any helper local variables to prepare some data to be used in view initializers:

var body: some View {
  HStack {
    let text = model.getText()
    // error: Closure containing a declaration cannot be used with function builder 'ViewBuilder'
    Text(text)
  }
}

Shouldn't Swift be able to figure out that since the result of model.getText() is assigned to a local variable, then it should just ignore it and not try to pass it to the builder?

[karim (Karim Nassar)]

yuck. Can you use them in the top-most body declaration scope? Ie:

var body: some View {
    let text = model.getText()
    return HStack {
         Text(text)
    }
}

(I haven't had a chance to download and play with the betas yet)

[Jakub_Suder]

@karim

Can you use them in the top-most body declaration scope?

Yup, you just need to remember to add the return then. The body of body is a normal method, it's when you get into a closure that's passed to a builder when things start to get weird.

[jawbroken]

@Jakub_Suder

I've just noticed another limitation of builders - apparently you can't use any helper local variables to prepare some data to be used in view initializers

I think everyone should be careful here to evaluate the proposal and not the current implementation in the Xcode beta for SwiftUI. As I understand it, your code sample should be valid according to the rules in the proposal.

[karim (Karim Nassar)]

While I understand that SwiftUI is not Function Builders, it is a motivating example of the language feature, and currently the only concrete implementation using it. So I don't think it's not relevant to discuss the feature in terms of that implementation...

At the very least, it is perfectly valid to use it as a lens through which to examine uses of the feature, and to point out how shortcomings in such an implementation can cause confusion and poor ergonomics for users of the language.

[karim (Karim Nassar)]

Well, that's at least reasonably discoverable.

[jawbroken]

@karim

While I understand that SwiftUI is not Function Builders, it is a motivating example of the language feature, and currently the only concrete implementation using it. So I don't think it's not relevant to discuss the feature in terms of that implementation...

Sure, it's a very relevant example but you shouldn't see the limitations of the current beta implementation as inherent to the feature, and it will get very confusing in here if people start evaluating the proposal on the merits of that implementation rather than the proposal itself.

@The Proposal

• Implementation: PR. Note that the implementation in the Xcode developer preview uses a somewhat simpler transformation than that described here. The linked PR reflects the implementation in the preview but is under active development to match this proposal.

[Paul_Cantrell]

Picking up on John’s terminology here:

@John_McCall

the original semantics of the function are preserved as much as possible, and it's just that some values are captured and built into the result

Maybe “value-capturing closure,” paralleling the grammar of “escaping closure” and “trailing closure?”

Or, to avoid confusion with the existing meaning “capture” in the context of closures, maybe “result-gathering closure?”

[trs (Thorsten Seitz)]

@anandabits

ViewBuillder combines the Text s into a TupleView and that is the return value of the builder closure. The result of this is that the full type of the VStack is VStack<TupleView<(Text, Text)>> . If you had used two images instead, it would be VStack<TupleView<(Image, Image)>> . It is also possible to capture heterogeneous values subview types this way, for example VStack<TupleView<(Image, Text, Color)>> . This type-level distinction is why function builders are necessary and a more familiar builder approach as seen in Ruby and Kotlin is insufficient.

I still don't get how this type-level distinction is used. Are there overloads of VStack's initializer with various TupleView type combinations to achieve some optimizations? I haven't seen any, so how is that type information actually used?

[laszlokorte]

@trs

I still don't get how this type-level distinction is used. Are there overloads of VStack's initializer with various TupleView type combinations to achieve some optimizations? I haven't seen any, so how is that type information actually used?

I guess knowing the full type of the entire View hierachy at compile time allows the compiler to allocate all the state properties in one block of memory which benefits caching and allows to produce optmized code paths for rerendering on all possible state changes. If you get away without type erasure you do not need any dynamc dispatches.

[John_McCall]

@kansaichris

With all due respect, this feels a bit contradictory to me. As far as I understand it, the whole raison d'être of this proposal—and the rejection of other alternatives like receiver closures—is SwiftUI's need for type propagation, which most users don't need, so by your logic, we shouldn't get hung up about type propagation, either, because most users don't need it.

That's a fair complaint, although I think there are other advantages to this approach beyond what receiver closures can express.

[anandabits (Matthew Johnson)]

@trs

I still don't get how this type-level distinction is used. Are there overloads of VStack's initializer with various TupleView type combinations to achieve some optimizations? I haven't seen any, so how is that type information actually used?

I believe SwiftUI is able to take advantage of the structural type-level information to provide better animations. If you spend some time playing around with it an explicitly introducing type erasure in the right places you should be able to observe this difference. It would be really cool if somebody spends the time to document this behavior, showing code samples and videos of the different animation results. That hasn’t been done yet though (as far as I know).

[flowtoolz (Sebastian Fichtner)]

@jawbroken

I don't find these sort of examples convincing (and generally don't like the use of “foo”, “bar”, etc in example code) because if you randomise the names of things in any piece of code then it becomes confusing. This is why names are so important, and why Swift has the API Design Guidelines document. For well-designed DSLs with reasonable names I'm not sure this will be a real issue. e.g. I haven't seen any SwiftUI code so far where I was confused about this.

I think the syntax should express the syntax. And the names should express the meaning. You can always encounter code that is very well named but from an unfamiliar application domain. In that case the syntax should be clear anyway.