- What is your evaluation of the proposal?
I’m very much in favour of function builders and the design as outlined in the proposal seems reasonable. It avoids being tied to specific syntactical constructs, especially since the removal of
buildDo. The concept of an (optional) internal currency type and an optional result type provides flexibility to DSL developers without imposing them on everyone, but I’m rather neutral on this specific aspect of the proposal. I’m a bit concerned about the builder methods being
static, which I discuss below.
- Is the problem being addressed significant enough to warrant a change to Swift?
Function builders are a major addition to the language (and therefore risky) but its prominent use in SwiftUI has proven the feature’s merit. It’s not merely syntactical sugar — it enables writing succinct code that fits nicely in the mould of a DSL. There are also DSLs outside of SwiftUI using it.
- Does this proposal fit well with the feel and direction of Swift?
Function builders are clearly an advanced language facility, but I feel that they fit well in the progressive disclosure philosophy. Users of a DSL shouldn’t need to learn anything about function builders except for using the annotation, but the DSL developer can easily explain this through tutorials and documentation.
Funnily, SwiftUI (and the concept of function builders) have defined a new direction for Swift a whole year before this proposal has been put for formal review. Overall, SwiftUI has had a positive reception, or at least I didn’t see a lot of complaints about its DSL. It had (and has) some sharp edges, but they are being addressed (or there’s the intention to address them) through compiler and language improvements that are mostly orthogonal to the function builders feature: for example, one-way type inference constraints and variable generics.
Since day 1, Swift has had several language features that enable (and even encourage) inventing DSLs within Swift, such as custom operators, auto-closures, and trailing closures. Function builders provide a big boost in this space. Just like the previously mentioned features, function builders should be used mindfully, but the possibility of (syntactical) abuse hasn’t been a successful argument against a language feature, as far as I know.
The builder methods are
static, which seems a bit un-Swifty to me (and Java-y instead). The builder type (like
ViewBuilder) merely acts as a container of methods instead of the type of builders. The
builder syntax doesn’t instantiate a
builder whereas property wrappers are instantiated using the
wrapper syntax. I don’t see a reason to introduce this inconsistency in the language. Additionally, some DSLs may enjoy having the flexibility of configuring the builder value on a per-annotation basis. An example can be found in the proposal document under Future Directions.
- If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I’ve used (and enjoyed using) Gradle —which uses Groovy’s DSL features— but I didn’t use Groovy for other purposes. I’m not aware of any DSL (non-macro) features from other languages. IMHO, Swift has the potential to popularise DSLs and be an inspiration for the programming community at large.
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I’ve been following this proposal since last year and I’ve enjoyed writing SwiftUI code. I’m also using
@_functionBuilder in some of my projects.