Add scala.collection.mutable.StringBuilder(CharSequence, start, end)

Design
1

scala.collection.mutable.StringBuilder has no API to append a substring, unlike the underlying java.lang.StringBuilder’s API to do so.

Can we add this to 2.13.3?

Also, a question:

I tried to write a “polyfill” using an extension method, but couldn’t make it work without changing the method name to append2. Is there a way to make this work with append?

implicit final class StringBuilderExtensions(val sb: StringBuilder) extends AnyVal {
  // append2 can't be named `append` because then the compiler won't
  // find the extension method and instead will convert an `append(s,
  // start, end)` call into `append(Tuple3[String, Int, Int])`.
  def append2(s: java.lang.CharSequence, start: Int, end: Int): StringBuilder = {
    sb.underlying.append(s, start, end)
    sb
  }
}
2

Adding a method would not be binary compatible. And unfortunately Scala 3.0 will use the 2.13 std lib so it can’t be changed for a while.

At least the auto-tupling shouldn’t happen anymore in Scala 3 (at least I thought that auto-tupling would be disabled or limited in Scala 3…). For now I don’t think it can be disabled. I would just call the method appendSlice or something like that instead.

2 Likes
3

In JAVA, according to this: http://titanium.cs.berkeley.edu/doc/java-langspec-1.0/13.doc.html#44953 , adding a method doesn not break binary compatibility…
Addition of more methods overloading a particular method name does not break compatibility with preexisting binaries. The method signature that the preexisting binary will use for method lookup is chosen by Java's method overload resolution algorithm at compile time (§15.11.2). (If Java had been designed so that the particular method to be executed was chosen at run time, then such an ambiguity might be detected at run time. Such a rule would imply that adding an additional overloaded method so as to make ambiguity possible at a call site became possible could break compatibility with an unknown number of preexisting binaries. See §13.4.22 for more discussion.)

The same is not the case for Scala?

4

The keyword is preexisting binaries. The 2.13.2 library also has to be compatible with future (e.g. 2.13.3) binaries.

1 Like
5

Makes sense, thanks!

Is there a good place to store this feature request for the 3.1 standard library? :slight_smile:

6

You can watch https://github.com/scala/scala-dev/issues/661