Given the current state of the proposal, -0.5.
During pitching I brought up two main concerns that were acknowledged but never addressed.
I believe functionBuilder is the wrong name. This feature is not about "building functions" nor defining a "builder of functions". At its heart its about defining a domain-specific language, but could also be viewed as a "source code transformation".
There's nothing in the pitch that describes why the name "function builder" is appropriate, and even the initial definition of "function builder" goes out of its way to clarify what it actually means:
At the very least the pitch is missing the acknowledgement of alternative names and rationale for why @functionBuilder is the best name. And at most, the feature is mis-named.
There is no help provided to a DSL author to know which methods they actually need to implement.
In every other scenario of "an author wanting to supplement behavior", the compiler provides information about what's going wrong on that type that prevents successful compilation.
For protocols, we get errors about not having implemented the properties and methods defined by the protocol. For attributes like @main, failing to provide the static func main() requirement results in a compiler error that: 'MyEntryPoint' is annotated with @main and must provide a main static function of type () -> Void or () throws -> Void.
What analogous help is there here? The proposal says I can decorate a type with @functionBuilder to "make it a function builder", but then an author is immediately abandoned and left wondering "... now what?". The likely answer to this is "read the documentation", yet an ongoing thread here is all about acknowledging the flaws in our documentation. Perhaps the 1.0 version of this will ship with great documentation. But what about 1.1 versions and beyond?
Providing type-based hints from the compiler about "what do I do next" is a raison d'être for Swift, and this feature is completely lacking them.
I like the feature and want to use it, but I don't think this proposed change is good enough.
Mixed. This proposal highlights a massive missing area in Swift: a proper macro feature. I've had several situations where I've wanted to do source-level transformations and generation of code as part of compilation, and it pains me to see, yet again, a one-off solution being baked into the compiler.
N/A
I've been avidly following along and experimenting with function builders on my own.