TLDR: I propose @StatementLifter.
Hello.
I've read this thread in broad strokes.
And I've seen some interesting conversations about many new names.
There are some good ideas,
but I'm writing because I got a better idea from there.
The name of function should be representation of how it works and what to do.
This is because it helps users who encounter the feature for the first time to understand details of the feature.
Many Builders variants are being talked about, including the original Function Builder.
But in my opinion, this direction is not the best.
Because while it does show what this feature can be used for, it doesn't explain how this feature works.
In fact, the builder pattern of programming is well known and this feature is useful for that, but the behavior of this feature itself is not a builder.
So what exactly does this feature do?
To clarify that, I thought about this feature again.
This feature is verfy powerful and magical.
It gives us the power to implement DSL in Swift.
So, on the contrary, why can't Swift successfully achieve DSL without this feature?
I think that's because Swift is statement oriented language.
It can be said that is is not expression oriented.
One of the big characteristics of Swift is that the control syntax, such as an if statement, is not an expression.
This characteristics brings order to codes.
It prevents the writing of overly complicated code that is difficult to understand.
On the other hand, when building DSL,
the control structure must be handled by the DSL processor.
The reason why language is more useful than just describing data is because it has a control structure.
So, unfortunately, as long as Swift is a statement oriented language, it can't handle DSL well.
Statements are not something that can be manipulated in Swift code.
I think the magic feature that can solve this dilemma is this new feature.
In other words, the magic of this feature is that it turns a statement oriented Swift into expression oriented partially.
This feature allows you to convert an if or while statement to a value of the corresponding data type while retaining its structure.
Value means that it is a class of expression in the language and can be subject to operations within the language.
This is why this feature is useful for DSL implementation.
By the way, in the realization of FunctionBuilder, a new one-way constraint was introduced in the compiler's internal type inferencer.
I feel that the need for this new element also corresponds to the introduction of a new level of notion of converting a statement into an expression.
Therefore, I think that if we are going to name this function, we should focus on its works of converting statements into expressions.
I thought about what would be an appropriate word to describe this conversion.
I think this works similarly to what Haskell calls a lift.
Lifting is the elevation of an object to a more flexible concept that can represent it as it is and can be treated integrally with its higher concepts.
In other words, I think we can say that this feature lifts statements to a specific type.
I therefore suggest the name @StatementLifter.