Just as concrete types like ViewBuilder or ShortcutBuilder refer to the single value produced by the builder, @returnValueBuilder refers to the single return value, not to the intermediary steps.
I had proposed @returnValueBuilder thinking of the Swift principle of clarity over brevity. I believe it is more precise than either @valueBuilder or @returnBuilder.
I believe all builders, whether associated with this feature or not, build a value of some kind so @valueBuilder does not seem any more descriptive to me than just @builder, which I think is too general a name for the attribute.
I also agree with @Jon_Shier that @returnBuilder on its own doesn't make too much sense, since there's no real precedent for 'return' to be used as a noun. (Although admittedly it is less of a mouthful / eyeful.)
I personally had rejected @resultBuilder as a name because the term 'result' is very general.
However, I had forgotten about @discardableResult which provides precedent in the language of using 'result' as a synonym for 'returnValue'.
The section on Type Methods in The Swift Programming Language describes the connection plainly:
“Because it’s not necessarily a mistake for code that calls the
advance(to:)method to ignore the return value, this function is marked with the@discardableResultattribute.”
The grammar also defines function-result and subscript-result as the parts of function and subscript declarations that declare the type of the return value.
Since there is already precedence for using the term 'result' to mean 'return value', I've changed my opinion about @resultBuilder and think it would also work well as a name.
For me the pros and cons for @resultBuilder as opposed to @returnValueBuilder are:
Pros:
- Consistency with the naming of
@discardableResult - Further establishes 'result' as a synonym for 'return value' in the language
- A more concise name without losing precision
(at least, precision in the context of how 'result' is formally used in the language).
Cons:
- It's not immediately evident that 'result' means 'return value' and could be confused with any expression result.
(On the other hand one could interpret the name 'result builder' as building not only the the final return value, but also building the result of each statement, which is also accurate.). - The connection within the diagnostic messages mentioned by @beccadax would be less direct.
I think that both @returnValueBuilder and @resultBuilder are suitable names, and I hope one of them is chosen.
My own personal preference now leans towards @resultBuilder because of the consistency with the existing usage of 'result' and because I believe it reads / writes / sounds better without losing clarity.