StringBuilder that uses an internal LongArray

[gavinking]

As per this comment on reddit, there is a usage pattern for StringBuilder that we've never really considered, and that seems to be extremely difficult to optimize given the current implementation.

But if StringBuilder were to store its characters in a Java LongArray, we could optimize the for loop to use by-index access.

The question is whether we could then make StringBuilder.string efficient enough. I think it's likely that we could, with some finesse. If not, then perhaps we just need a separate class (StringBuffer??) that behaves like this. The idea being that it's not meant for "building strings", but for aggregating and reading Characters.

Those really are two separate usage patterns, actually.

[jvasileff]

It seems to me that:

1. Using StringBuilder to create a string is a much more common use case than non-native character iteration , and
2. With compiler support, there should be some way to optimize away boxing for iteration without changing the underlying storage. Either the compiled code or some helper class would need access to the builder. Maybe some visibility trick. Or, even just hiding "efficient" iteration methods in the object returned by iterator(), and having the compiler perform a cast to gain access to the methods.

This doesn't address random access, but a growable Character list sounds more ArrayList<Character> than a StringBuilder.

[gavinking]

@jvasileff well the issue is that now that StringBuilder is written in pure Ceylon, it's harder to insert backdoors for the compiler to get at its chars.

[jvasileff]

The object returned by iterator() could satisfy ceylon.language.impl::CharacterIterator with members hasNext and nextCharacter().