Looks like 2.13 varargs uses immutable.Seq?

[olafurpg]

cat match.scala
object a { def foo(x: String*): Unit = () }

coursier launch org.scala-lang:scala-compiler:2.12.7 -M scala.tools.nsc.Main -- -classpath $(coursier fetch org.scala-lang:scala-library:2.12.7) match.scala
javap a
public final class a {
  public static void foo(scala.collection.Seq<java.lang.String>);
}

coursier launch org.scala-lang:scala-compiler:2.13.0-M5 -M scala.tools.nsc.Main -- -classpath $(coursier fetch org.scala-lang:scala-library:2.13.0-M5) match.scala
javap a
public final class a {
  public static void foo(scala.collection.immutable.Seq<java.lang.String>);
}

Observe the difference

- 2.12.7
+ 2.13.0-M5

-  public static void foo(scala.collection.Seq<java.lang.String>);
+  public static void foo(scala.collection.immutable.Seq<java.lang.String>);

Has this change been discussed by the SIP committee?

[SethTisue]

this was part of the collections redesign. I don't recall if this specific aspect was discussed by the committee or not

I see now that https://github.com/scala/scala/releases/v2.13.0-M4 just says "scala.Seq is now an alias for scala.collection.immutable.Seq (no longer scala.collection.Seq)" but doesn't mention that varargs are affected as well; I've added "(note that this also changes the type of Scala varargs methods)". (The various milestone and RC release notes will eventually be combined into unified 2.13.0 release notes.)

[olafurpg]

Repeated arguments are a language feature so I would expect this change to go through the SIP committee. IIUC, there are plans to make varargs immutable arrays in Dotty so it would be great to consolidate breaking changes.

EDIT: s/regular arrays/immutable arrays/

[NthPortal]

See also scala/bug#11040, scala/scala#6962 and scala/bug#11024

[olafurpg]

Thanks for the links @NthPortal

This ticket is a question about the process behind this decision and can be closed with an answer: "changing varargs to immutable.Seq does not require a SIP discussion". I would argue that this change does require a SIP discussion because it changes the language in a significant way: a 2.12 library using varargs can't possibly expose the same API on 2.13. Changing the Seq type alias in the standard library is a different thing because libraries can work around it.

[lrytz]

The spec says

The type of such a repeated parameter inside the method is then the sequence type scala.Seq[T]

So no change to the spec was necessary. But it's a change in a part of the library that the spec depends on.

[dwijnand]

Yeah, so it's transitively a language change.

a 2.12 library using varargs can't possibly expose the same API on 2.13

@olafurpg do you have any examples of this? Perhaps we can work backwards from the problem to find a way forward.

[olafurpg]

@dwijnand Every 2.12 library that uses varargs is an example of this. There is no migration strategy for upgrading to 2.13 that allows libraries to preserve the semantics of vararg methods.

@lrytz fair enough, that is a sufficient answer to close this ticket. My recommendation is still to let the SIP committee discuss this change, especially to evaluate whether immutable.Seq varargs are a permanent solution or temporary until Scala 3 comes out.

[SethTisue]

@darjutak I guess this should be added to an upcoming SIP agenda

[SethTisue]

note that over at https://github.com/lampepfl/dotty/issues/5698 , Martin is proposing having varargs be typed with an "immutable" array wrapper rather than immutable.Seq

[smarter]

Reopening since in the SIP meeting we agreed we would try making varargs use scala.collection.Seq and see how that affects the community build. The main reason being that in 2.14 it's likely we would change the varargs representation again to something more abstract.

[jrudolph]

In https://contributors.scala-lang.org/t/tools-for-cross-building-code-with-2-13/2786 we discuss some compatibility problems we found in maintaining the akka-http cross-build for 2.12 / 2.13 regarding this change.

• From Scala, you will not see this type at the call-site so it would be good if it couldn't conflict with any overloads at all. In the varargs method itself, I guess any subtype of immutable.Seq would be fine.
• Is it a concern how easy it is to call Scala varargs methods from Java?
• To support the : _* syntax, using Seq was nice because it meant that passing in most collection types was cheap because they could internally be passed in as is. If the new type in the signature isn't in the type hierarchy then passing in an existing collection via : _* will need at least some wrapping and at worst a copy of the collection into the new form (or restrict the source collection types supported with :_*).

In the end, the type which to put into the signature seems like an implementation artifact. On the call site, you want : _* to work for as many collections as possible for convenience, in the method itself, the type (which is not mentioned in the source code) could probably be just immutable.Seq. That shouldn't actually affect what the concrete type is that the Scala compiler puts into the signature (at least if it's a subtype of immutable.Seq or whatever the method definition sees).

[szeiger]

Here's an attempt at making varargs mutable again: scala/scala#7703