# SE-0289: Function Builders

**URL:** <https://forums.swift.org/t/se-0289-function-builders/39889>\
**Category:** Proposal Reviews\
**Created:** [August 31, 2020, 3:30pm UTC](https://forums.swift.org/t/se-0289-function-builders/39889 "2020-08-31T15:30:35Z")\
**Posts on this page:** 20\
**Page:** 4

<div class="post-metadata">

**Author:** ![Jumhyn](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jumhyn/32/3891_2.png) [@Jumhyn](https://forums.swift.org/u/Jumhyn)\
**Post date:** [September 6, 2020, 5:05pm UTC](https://forums.swift.org/t/se-0289-function-builders/39889/62 "2020-09-06T17:05:23Z")

</div>

Yeah, nailing down the actual requirements for each of the `build*` functions would be awesome. The main distinction that needs to be made, IMO, is whether there are hard restrictions on the form that a `build*` _declaration_ can take (e.g., require a certain number of arguments, require it to be a `static func`), or if we're more concerned about having the function builder transformation produce a syntactically valid call within the transformed closure.

In the latter case, it would be acceptable for, e.g., `buildExpression` declarations to take any form within the builder type so long as it could be invoked as `Builder.buildExpression(partialResult)`. This is already the case for `buildBlock`, where supremely weird constructions like:

```swift
@_functionBuilder
enum EnumBuilder {
    case buildBlock(Any)
}

@EnumBuilder var x: EnumBuilder { 1 }

```

are perfectly valid, because `EnumBuilder.buildBlock(1)` compiles without issue (as I hinted at above).

Right now, the actual constraints on the `build*` requirements are pretty under-specified. IMO we should err on the side of being more restrictive in terms of the allowed forms of `build*` declarations—we can always loosen restrictions later.

---

<div class="post-metadata">

**Author:** ![Lantua](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lantua/32/8868_2.png) [@Lantua](https://forums.swift.org/u/Lantua)\
**Post date:** [September 6, 2020, 5:36pm UTC](https://forums.swift.org/t/se-0289-function-builders/39889/63 "2020-09-06T17:36:58Z")

</div>

I think that the function builder should parse much the same way that `StringInterpolation` parses `appendInterpolation`, allowing defaulted values.

---

<div class="post-metadata">

**Author:** ![Jon\_Hull](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon_hull/32/678_2.png) [@Jon\_Hull](https://forums.swift.org/u/Jon_Hull)\
**Post date:** [September 7, 2020, 1:09am UTC](https://forums.swift.org/t/se-0289-function-builders/39889/64 "2020-09-07T01:09:57Z")

</div>

How about `@FunctionDSL` because that is what it is...

The functions would be `dsl(expression:)`, etc...

---

<div class="post-metadata">

**Author:** ![lassejansen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lassejansen/32/4712_2.png) [@lassejansen](https://forums.swift.org/u/lassejansen)\
**Post date:** [September 7, 2020, 8:51am UTC](https://forums.swift.org/t/se-0289-function-builders/39889/65 "2020-09-07T08:51:20Z")

</div>

> [@Douglas\_Gregor](#):
>
> Perhaps we should do a standalone `ArrayBuilder` like this one (...) but this is less flexible.

If ArrayBuilder would be implemented as a class instead of an enum it would support most of the "common" use cases I think, by allowing to implement additional `buildExpression` and `buildFinalResult` methods in subclasses.

> [@Douglas\_Gregor](#):
>
> It doesn't look like the shape of the library API we end up here will influence the language proposal, and enough questions remain about the library that it's not worth tying the two together.

Makes sense. Thanks for your work on this, looking forward to use function builders in production code.

---

<div class="post-metadata">

**Author:** ![odmir](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/odmir/32/4784_2.png) [@odmir](https://forums.swift.org/u/odmir)\
**Post date:** [September 7, 2020, 6:57pm UTC](https://forums.swift.org/t/se-0289-function-builders/39889/66 "2020-09-07T18:57:00Z")

</div>

Hmm I feel like `collect` would be a more natural name for these functions, no?

---

<div class="post-metadata">

**Author:** ![SwiftUI](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/swiftui/32/24361_2.png) [@SwiftUI](https://forums.swift.org/u/SwiftUI)\
**Post date:** [September 7, 2020, 7:16pm UTC](https://forums.swift.org/t/se-0289-function-builders/39889/67 "2020-09-07T19:16:58Z")

</div>

Speaking of the name, `@_functionBuilder` as an attribute providing a set of `build* functions` definitions, so name it as functionBuilder is reasonable but not concise enough to developers. Maybe `@DSL` is much shorter and easy to remember.

In Swift, `build* something called as @somethingBuilder ` already seems like a convention, e.g. in SwiftUI build view called as @ViewBuilder. Looking forward to @JSONBuilder @GraphQLBuilder @XMLBuilder or even @Builder, don't be surprised @SwiftBuilder guys ~ 😃

---

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [September 8, 2020, 3:13am UTC](https://forums.swift.org/t/se-0289-function-builders/39889/68 "2020-09-08T03:13:14Z")

</div>

Swift generally prioritizes clarity for the reader over saving a small number of keystrokes. That applies especially strongly to this feature, which is expected to be an interesting tool for a small number of library writers rather than something that most developers will be writing themselves.

---

<div class="post-metadata">

**Author:** ![Lantua](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lantua/32/8868_2.png) [@Lantua](https://forums.swift.org/u/Lantua)\
**Post date:** [September 8, 2020, 10:44am UTC](https://forums.swift.org/t/se-0289-function-builders/39889/69 "2020-09-08T10:44:40Z")

</div>

Even further, Swift doesn't shy away from adding verbosity to avoid unintended usage and collision with existing names, e.g. `callAsFunction` ([SE-0253](https://forums.swift.org/t/accepted-with-modification-se-0253-callable-values-of-user-defined-nominal-types/24605)), and I believe that opinion still stands today.

That said, it doesn't necessarily apply to function builder. The builder already needs to apply `@functionBuilder`, and the chance of collision would be very low. Still, _clarity over brevity_ is a very normally Swifty thing to say.

---

<div class="post-metadata">

**Author:** ![tevelee](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tevelee/32/9775_2.png) [@tevelee](https://forums.swift.org/u/tevelee)\
**Post date:** [September 8, 2020, 10:57am UTC](https://forums.swift.org/t/se-0289-function-builders/39889/70 "2020-09-08T10:57:32Z")

</div>

> Swift generally prioritizes clarity for the reader over saving a small number of keystrokes. That applies especially strongly to this feature

I somewhat disagree that the same level of clarity applies to this feature as well. If we take a look at the following two code snippets, their call sites are practically the same, but one uses a function builder for the body, the other does not. This distinction is not visible when looking at just the call site itself.

```
import SwiftUI

struct SwiftUIView: View {
    var body: some View {
        let name = "swift"
        Image(systemName: name)
        Text("Swift")
    }
}

struct DoesNotUseFunctionBuilder {
    var body: Any {
        let name = "swift"
        Image(systemName: name)
        Text("Swift")
    }
}

```

(The first one is completely valid, but the second one obviously does not compile because of the missing return statement in a non-functionBuilder environment.)

---

<div class="post-metadata">

**Author:** ![JoeyKL](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joeykl/32/3140_2.png) [@JoeyKL](https://forums.swift.org/u/JoeyKL)\
**Post date:** [September 8, 2020, 4:35pm UTC](https://forums.swift.org/t/se-0289-function-builders/39889/71 "2020-09-08T16:35:25Z")

</div>

> [@Douglas\_Gregor](#):
>
> It doesn't look like the shape of the library API we end up here will influence the language proposal, and enough questions remain about the library that it's not worth tying the two together.

Yeah, fair enough. It’s not particularly important that it ends up in this proposal, but I do think it’s important that it ends up in the same Swift release. I think a deluge of unnecessary functionbuilder types will result in widespread confusion about what they actually do.

---

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [September 8, 2020, 4:56pm UTC](https://forums.swift.org/t/se-0289-function-builders/39889/72 "2020-09-08T16:56:55Z")

</div>

> [@jrose](#):
>
> That said, I re-read the "no `buildEither` " behavior and I'm a little surprised that it _unconditionally_ injects values into optionals, rather than having that depend on the exhaustiveness of the switch. Was that intentional, Doug?

Switches need to be exhaustive. What am I missing?

> [@Lantua](#):
>
> We should also clarify how types propagate through variables:
> 
> ````swift
> @FooBuilder
> func foo(@FooBuilder closure: () -> Foo) -> Foo { ... }
> 
> // (() -> Foo) -> Foo
> // NOT @FooBuilder (@FooBuilder () -> Foo) -> Foo
> let a = ```
> 
> ````
> 
> This would be akin to treating builder annotation as part of the function name, not function type. So maybe we'll need to permit it when referring to function names:
> 
> ```swift
> let a = foo(@FooBuilder _:)
> 
> ```

I don't see what needs clarification here. The attribute is allowed on a parameter; it is not part of the type.

> [@Lantua](#):
>
> We shouldn't allow builder annotation at non-argument location in the protocol requirement:
> 
> ```swift
> protocol Foo
> // Bad Ok
> // | |
> @FooBuilder func foo(@FooBuilder _: () -> Foo) -> Foo
> 
> ```
> 
> One reason is that we never permit implementation details in the protocol requirements, even for property wrapper, which is half-implementation half-interface\*. It calls into question of how much should be allowed in a protocol declaration, which I think should only be information relevant to the caller.

Putting a function builder attribute on a protocol member [infers that attribute](https://github.com/apple/swift-evolution/blob/master/proposals/0289-function-builders.md#inferring-function-builders-from-protocol-requirements) for declarations that satisfy that requirement.

> [@Lantua](#):
>
> The reader needs to know that `Conformer` conforms to a protocol, that it requires `foo` , and that `foo` is annotated with `@FooBuilder` in the protocol requirement.

I could make the same argument about inferring `@FooBuilder` for a closure passed to a parameter. This feature is mostly implicit at the use site. It's disabled by an explicit `return`, so you're already writing in a function-builder-esque style where you have value-producing expressions as statements if it's going to do anything.

> [@jrose](#):
>
> If you implement `buildExpression` for _some_ types, do expressions with _other_ types just get passed through verbatim? I'd suggest "no"; if you want that behavior you can opt in with a fallback `buildExpression` that has an unconstrained generic parameter. You only get the "default" behavior if there are _no_ overloads of the thing.

As [@Lantua answered](https://forums.swift.org/t/se-0289-function-builders/39889/55), the answer is "no". Defining any `buildExpression` means all values go through it, and you control what values are permitted and how they get type checked.

> [@jrose](#):
>
> I agree with @Lantua about dropping `Void` results by default. That would allow the use of assertions and assignments in the middle of a builder, making it more like "normal code with collected results". Having to make your component type optional just so you can filter out Void seems icky.

Not sure I addressed this before, but I disagree here: this should be under the control of the function builder. If it is the case that something like `ArrayBuilder` will be the common case, it can make this easier for folks.

> [@jrose](#):
>
> I agree with @davedelong and others that having a bunch of optional syntactic customization points makes it hard for the compiler to help you define a function builder.

Requiring `buildBlock` to help folks get started + better code completion support will go a long way toward discoverability here.

> [@mayoff](#):
>
> The current implementation allows a `build` method to take extra arguments with default values.

That falls out of the syntactic transformation that defines this feature.

> [@Jumhyn](#):
>
> Right now, the actual constraints on the `build*` requirements are pretty under-specified. IMO we should err on the side of being more restrictive in terms of the allowed forms of `build*` declarations

I'm fine with constraining them to be functions (not properties or enum cases, for example), but we shouldn't over-specify them: the syntactic transformation to a call is the right way to describe this behavior.

Doug

---

<div class="post-metadata">

**Author:** ![Lantua](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lantua/32/8868_2.png) [@Lantua](https://forums.swift.org/u/Lantua)\
**Post date:** [September 8, 2020, 5:11pm UTC](https://forums.swift.org/t/se-0289-function-builders/39889/73 "2020-09-08T17:11:22Z")

</div>

> [@Douglas\_Gregor](#):
>
> I don't see what needs clarification here.

At least, I think it's not clear whether `@FooBuilder` will be part of function identification, whether this is allowed:

```swift
let a = foo(@FooBuilder _:)

```

and whether these two collide:

```swift
func a(@FooBuilder _: () -> Foo)
func a(_: () -> Foo)

```

> [@Douglas\_Gregor](#):
>
> I could make the same argument about inferring `@FooBuilder` for a closure passed to a parameter. This feature is mostly implicit at the use site.

The declaration site has much more weight, though. Especially that it's the place you go to when looking up the use site. So at the very least, you can know that `a { ... }` is invoking:

```swift
func a(_: @Builder () -> Foo)

```

but I don't expect subsequent readers to be able to look up the protocol that `body` implements. So unless IDEs (and LSP) start adding _jump to Protocol Requirement_ in parallel to _jump to Definition_, inferring attributes from protocol requirements are a lot more obscure compared to inferring attributes from definitions.

---

<div class="post-metadata">

**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\
**Post date:** [September 8, 2020, 5:11pm UTC](https://forums.swift.org/t/se-0289-function-builders/39889/74 "2020-09-08T17:11:54Z")

</div>

> [@Douglas\_Gregor](#):
>
> > [@jrose](#):
> >
> > That said, I re-read the "no `buildEither` " behavior and I'm a little surprised that it _unconditionally_ injects values into optionals, rather than having that depend on the exhaustiveness of the switch. Was that intentional, Doug?
> 
> Switches need to be exhaustive. What am I missing?

I guess I should have said "selection statement", but regardless: in the "injection tree" form, there's this line:

> - Finally, if there are any non-result-producing cases, the expression is wrapped in `Optional.some`.

i.e. if all cases _do_ produce results, there's no extra wrapping and nothing goes through `buildOptional(_:)`. But the "not using an injection tree" case says this:

> - If the statement is not using an injection tree, the combined result is wrapped in `Optional.Some` and assigned to the appropriate `vCase`.

and then the final part says

> After the statement, if the statement is not using an injection tree or if there are any non-result-producing cases [`buildOptional(_:)` is called]

I think that wrapping and the use of `buildOptional(_:)` should still be conditional on whether there are non-result-producing cases, which would allow a builder to not support optional partial results but still allow inline specification of alternatives. (As I mentioned earlier to Lantua, alternatives-without-absences makes sense to support by default because you can always resolve alternatives manually using `?:`.)

---

<div class="post-metadata">

**Author:** ![James\_Dempsey](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/james_dempsey/32/14336_2.png) [@James\_Dempsey](https://forums.swift.org/u/James_Dempsey)\
**Post date:** [September 8, 2020, 5:15pm UTC](https://forums.swift.org/t/se-0289-function-builders/39889/75 "2020-09-08T17:15:45Z")

</div>

I've been using the proposed feature in SwiftUI since it was introduced last year. But I'm only now digging into the mechanism being proposed.

Overall my experience with the feature has been positive. However, I am a very strong -1 on the name of the attribute.

I believe the attribute name _@‍functionBuilder_ is very misleading and immediately gives someone new to the feature an incorrect mental model of what the feature does and how it works.

This feature proposal introduces one attribute and seven methods, but the largest API surface area related to this feature will be the names of types that implement this feature in a wide variety of frameworks. So, I think it makes sense to talk about the naming of the attribute and its related methods in that context.

A strong naming convention for these types is already evident among the projects mentioned in the proposal and in examples used in the proposal:

**SwiftUI:** ViewBuilder, SceneBuilder, CommandsBuilder, ToolbarItemsBuilder

**swift-shortcuts:** ShortcutBuilder

**swift-css:** StylesheetBuilder, CSSBuilder

**Proposal examples:** TupleBuilder and HTMLBuilder.

This naming convention evokes the classic Builder design pattern as a type that builds instances of another type.

I support this naming convention because it seems natural, straightforward, and easy to understand. A ViewBuilder builds views. A ShortcutBuilder builds shortcuts.

Of course, it would naturally follow that a function builder builds functions.

Well, no. A function builder doesn't do that at all.

Based on the description of the feature, the only way I can wrap my head around the name _@‍functionBuilder_ and have it make sense is the following:

A ‘function builder’ is something that takes the body of a function and transforms it using a transformation known as ‘building’. So a function builder is something that acts upon they body of a function to perform something called building on it.

I don't know if that is the correct rationale for the proposed name, but it is the only interpretation I can think of that makes some sense to me.

That interpretation is analogous to calling a home builder a ‘raw material builder’ as someone who takes raw materials and transforms them into a home using a process known as building.

Both are awkward phrases that do not map to how the that phrase is usually parsed and understood by a reader.

So, just in reading the name of the feature or attribute, most will assume a _@‍functionBuilder_ creates functions and immediately have an incorrect notion of what the feature is and how it works.

**More than a function builder**

Another issue with the name _@‍functionBuilder_ is that it performs its transformation on more than just functions. It also performs them on the getters of computed variables and subscripts. (Perhaps those getters are implemented as anonymous functions at a low level, but to most Swift users, functions, variables, and subscripts are distinct things with different rules for declaration and usage.)

In SwiftUI's public API, no function declarations have a function builder attribute, the only declarations with the attribute are for variables. The other common usage in SwiftUI being as parameter attributes on function types. This also seems to be a common pattern in the other projects listed in the proposal.

It raises the question, why does a function builder work on things that aren't functions?

The use of ‘function’ in the attribute name seems very imprecise, since the builder can transform the body of Swift declarations other than functions, especially since transforming a non-function declaration (var) is one of the most common uses of the feature.

**Is it a term of art?**

I am not very well versed in classic functional programming terminology. So, I thought _function builder_ might be an existing term of art.

A Google search for _function builder_ largely turns up two types of results:

- Pages about things that create functions

- Articles about this feature in Swift

It does not appear that the term _function builder_ as used in this proposal is an existing term of art. It does seem like the use of the term _function builder_ in this proposal uses a meaning for the phrase that is different from how the phrase is commonly used and understood.

The term _builder_ on its own is a known term of art referring to the Builder design pattern.

**Proposed Attribute Name**

I propose the attribute name _@‍returnValueBuilder_.

The name follows the natural naming pattern of its concrete types such as ViewBuilder, SceneBuilder, etc. Its name also answers the question, what does a _@‍returnValueBuilder_ do? It builds return values.

The name accurately and precisely describes what is built by every type with this annotation. The term _return value_ is used extensively and consistently throughout Swift documentation and applies to functions, closures, computed property getters, and subscript getters.

Finally, it retains the term _builder_ which is a well-known design pattern that accurately describes types that implement this feature, but avoids using it in a phrasing that is awkward and unfamiliar to the reader.

**Alternatives Considered**

_@‍builder_ is very concise and avoids the need for the attribute to specify a general term for what it builds. My main concern is that it is a very general term that could cause confusion with any other sort of builder-style mechanism that might be introduced in Swift itself or in developer code.

_@‍resultBuilder_ is shorter, but less precise. A _@‍returnValueBuilder_ always builds a return value, not just any result.

_@‍functionTransformer_ has the issue that the bodies of non-functions can be transformed as well. Also, it is a very general term not indicating at all how the function is transformed. For example, it could be something that transforms a function that returns an Int into a function that returns a String.

One point related _@‍functionTransformer_ is that the name _@‍returnValueBuilder_ doesn't specify _how_ the type builds a return value. But I think it is more important for the attribute to indicate the purpose of the type, what it is, as opposed to its underlying implementation. Similarly, just by reading the name, we know that a _@‍propertyWrapper_ wraps a property. We don't know exactly how to implement one without learning more about the feature.

_@‍bodyBuilder_ This one is included because it is difficult for me to resist a pun. It still uses the awkward phrasing of _@‍functionBuilder_ by referring to what it acts upon, as opposed to what it creates, but it does more accurately reflect that it acts on the body of things other than functions as well.

**Proposed Method Names**

While I am strongly against the name _@‍functionBuilder_ and think a better alternative should be adopted, I do not have as strong an opinion about the names of the seven _build..._ methods themselves.

As developers, we often think of 'build' as a noun as well as a verb. (Don't break the build!) So reading a name like 'buildExpression' I sometimes parse it as an expression that has something to do with a build, as opposed to a command to build an expression.

As the discussion regarding method names continues, I'd like to note that a home builder can pour a foundation, frame a house, and rough-in electrical wiring. So, generally speaking, a builder can perform verbs that are more specific or precise than 'build'.

**Conclusion**

I believe this feature / attribute is an important one in Swift and deserves to have a name that is not immediately misleading and that accurately describes types that adopt this attribute. I don't believe that _@‍functionBuilder_ meets this standard and propose that _@‍returnValueBuilder_ does.

---

<div class="post-metadata">

**Author:** ![Jon\_Shier](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon_shier/32/921_2.png) [@Jon\_Shier](https://forums.swift.org/u/Jon_Shier)\
**Post date:** [September 8, 2020, 5:33pm UTC](https://forums.swift.org/t/se-0289-function-builders/39889/76 "2020-09-08T17:33:55Z")

</div>

I think `@valueBuilder` should also be considered. I’m not sure `return` really adds anything.

---

<div class="post-metadata">

**Author:** ![James\_Dempsey](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/james_dempsey/32/14336_2.png) [@James\_Dempsey](https://forums.swift.org/u/James_Dempsey)\
**Post date:** [September 8, 2020, 5:39pm UTC](https://forums.swift.org/t/se-0289-function-builders/39889/77 "2020-09-08T17:39:58Z")

</div>

> [@Jon\_Shier](#):
>
> I think `@valueBuilder` should also be considered. I’m not sure `return` really adds anything.

I agree `@valueBuilder` would be a much improved alternative.

For me `@returnValueBuilder` strongly indicates something that doesn't just build values that can be used anywhere, but builds values that are specifically used as return values, which implies use only in the context of functions and getters.

---

<div class="post-metadata">

**Author:** ![Jon\_Shier](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon_shier/32/921_2.png) [@Jon\_Shier](https://forums.swift.org/u/Jon_Shier)\
**Post date:** [September 8, 2020, 5:42pm UTC](https://forums.swift.org/t/se-0289-function-builders/39889/78 "2020-09-08T17:42:19Z")

</div>

I'm not sure most users would have such a precise understanding of the feature but I see your point.

---

<div class="post-metadata">

**Author:** ![toph42](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/toph42/32/7807_2.png) [@toph42](https://forums.swift.org/u/toph42)\
**Post date:** [September 8, 2020, 5:57pm UTC](https://forums.swift.org/t/se-0289-function-builders/39889/79 "2020-09-08T17:57:10Z")

</div>

It took quite some time for my “mind’s eye” to see the feature in the correct light, as the “function” part of the name led me astray. I agree with the suggestion of `@valueBuilder` though I was leaning towards `@builder` before the explanation of why that was considered and rejected (though I have no idea what those other referenced future things might be).

---

<div class="post-metadata">

**Author:** ![James\_Dempsey](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/james_dempsey/32/14336_2.png) [@James\_Dempsey](https://forums.swift.org/u/James_Dempsey)\
**Post date:** [September 8, 2020, 6:07pm UTC](https://forums.swift.org/t/se-0289-function-builders/39889/80 "2020-09-08T18:07:43Z")

</div>

> [@toph42](#):
>
> I was leaning towards `@builder` before the explanation of why that was considered and rejected (though I have no idea what those other referenced future things might be).

I just want to clarify that those were all alternative names that I personally considered when writing up my feedback. I don't think that `@builder` has been considered and rejected overall.

---

<div class="post-metadata">

**Author:** ![SwiftUI](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/swiftui/32/24361_2.png) [@SwiftUI](https://forums.swift.org/u/SwiftUI)\
**Post date:** [September 8, 2020, 7:49pm UTC](https://forums.swift.org/t/se-0289-function-builders/39889/81 "2020-09-08T19:49:06Z")

</div>

Personally, I prefer @resultBuilder rather than @resultValueBuilder, since it builds from a list of partial results into a whole new final result - the process we called transformation.

Of course, for general term @Builder has no problem, use @Builder attribute to define and build other @\*Builder DSL is well reasonable, that makes perfect sense to developers.

[Previous page](https://forums.swift.org/t/se-0289-function-builders/39889.md?page=3)

[Next page](https://forums.swift.org/t/se-0289-function-builders/39889.md?page=5)