Proposal Details

There is currently no support for appending the result of any of the string transformation functions¹ (Join, Replace(All)?, Repeat, Map, To(Title|Upper|Lower)(Special)?, ToValidUtf8) directly to a Builder, bypassing the intermediate temporary allocation:

// var b strings.Builder (assume that the backing buffer has been preallocated)
s := strings.Repeat(...) // intermediate temporary allocation
b.WriteString(s) // s dead here

The necessary presence of that temporary allocation partially defeats the purpose of Builder. I most recently ran into this while building SQL queries with varying number of placeholders (Repeat) and columns (Join).

Any of the following would address this issue, with different tradeoffs:

1. somehow ensure that the compiler is able to elide that intermediate temporary allocation
2. add variants of the transformation functions¹ that target either a Builder (or more in general a io.Writer, but in this case we will still want to add special handling for the case in which the io.Writer is a Builder) -- e.g. for function Foo(...) string we would get something like AppendFoo(*Builder, ...) int or AppendFoo(io.Writer, ...) (int, error)²
3. add a wrapper type in package strings that can be used to add all these string transformation methods¹ to an existing io.Writer (again, with the case of the io.Writer being a Builder being handled specially) -- e.g. for function Foo(...) string we would get something like WriteWapper(io.Writer).Foo(...) (int, error)²

Option 1 would be possibly the best from a user perspective, as it would transparently apply to existing code and would not require new APIs (nor a full-blown proposal), but seems a bit tricky as it would involve teaching the compiler about some of these functions/types and/or significantly strengthening escape analysis.

Option 2 and 3 could be useful beyond strings.Builder, but they require duplicating a number of existing APIs.