[Pitch #2] Function builders

Evolution Pitches
63

I was thinking about why the current design makes me somewhat uncomfortable, and I think I've partially figured it out. Of 28 uses of @_functionbuilder in projects linked in the awesome-function-builders repository:

  • 14, half, only implement buildBlock and all to a common return type.

  • 9 implement methods other than buildBlock, but all to a common return type, and only to implement a simple monoid operation (or in 1 case a semigroup operation).

  • 5 implement methods with differing return types / special behavior different methods. (One I think unnecessarily; three for in UI libraries (two of which are modeled after SwiftUI specifically); one for GraphQL queries).

I think the most obvious takeaway for this is that the function builder API should expose a way to more easily implement function builders for the most common use case, building static data structures under a monoid operation. This could be accomplished by either by defaulting to buildArray when no buildBlock is specified or by separating it into one implementation explicitly for loops and one for a single-method way to define a full builder that accepts control flow.

1 Like