Useful potential method: `joinToString`, but instead of a `transform` lambda, it takes `build: Strin...

# stdlib

[Derek Peirce]

Useful potential method: joinToString, but instead of a transform lambda, it takes build: StringBuilder.(T) -> Unit. That avoids creating intermediate strings for each element if multiple append calls would be more efficient.

[Derek Peirce]

Currently looking at a good use-case in which the string is built with StringBuilder, but the loop has an isNotEmpty check to decide whether or not to include the separator.

[ephemient]

I have wanted that on a few occasions, but StringBuilder receiver is too powerful, because the block can insert(0, ...) and break the separation

[ephemient]

maybe Appendable though?

[Derek Peirce]

Appendable looks like it should work just as well.

[ephemient]

(but the Kotlin interface requires you to stringify inputs first, which brings us back to the original issue with unnecessary intermediates)

[Derek Peirce]

Which interface is requiring that?

[ephemient]

https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.text/-appendable/

[ephemient]

(which is basically the same signature as the Java interface, minus throws IOException)

[Derek Peirce]

Is the issue that it doesn't also have append for primitives and Any? Are those implemented more efficiently than calling toString? I would doubt it.

[ephemient]

as an almost-as-concise workaround, if you have a fixed delimiter you could just always append it and then truncate it 🙂

entries.fold(StringBuilder()) { sb, (key, value) -> sb.append(key).append('=').append(value).append(", ") }.dropLast(2)

[Dominaezzz]

You can also have something like the original suggestion but have the standard library always supply an empty builder into the lambda, then copy the result over. So it'll be managing two string builders.

[Derek Peirce]

Is that any more efficient than just using the existing joinToString and buildString manually? The goal is to not create intermediate strings and copying.

[Dominaezzz]

Yeah sure, the copying is still there but I've reduced the number of allocations to just 2 ish.

[Dominaezzz]

Whilst still maintaining safety, so to speak

[Derek Peirce]

Using Appendable preserves safety while matching the performance of a hand-written buildString and loop.

[Derek Peirce]

The fold can work, but it's much more difficult to read to understand what it's trying to do compared to joinToString, or update it safely (the dropLast must match the separator size), and I can't tell from the documentation how efficient StringBuilder.dropLast actually is.

[Dominaezzz]

Appendable requires a string though, so you pay for the conversion to strings anyway.

[Derek Peirce]

Under the hood, StringBuilder.append(int) still calls toString, so with a few extensipn methods on Appendable, we end up with the same API and the same number of strings.

[ilya.gorbunov]

Note that there's also joinTo function, that takes an Appendable. However it still transforms each element to a string before appending it.