- What is your evaluation of the proposal?
Big +1.
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.