Skip to content
This repository was archived by the owner on Dec 22, 2021. It is now read-only.

FAQ

Jump to bottom
Julien Richard-Foy edited this page Apr 25, 2018 · 90 revisions

This page should evolve over time, but already be useful now. When more official documentation is available, content can be replaced by links.

Collection Users

What are the breaking changes?

The following table summarizes the main changes:

Description Old Code New Code Automatic Migration Rule
Method to[C[_]] has been removed (it might be reintroduced but deprecated, though) xs.to[List] xs.to(List) v0
SortedSet: the to, until and from methods are now called rangeTo, rangeUntil and rangeFrom, respectively xs.until(42) xs.rangeUntil(42)
immutable.Set/Map: the + operation no longer has an overload accepting multiple values Set(1) + (2, 3) Set(1) + 2 + 3
mutable.Set/Map no longer have a + operation mutable.Set(1) + 2 mutable.Set(1).clone() += 2
mutable.Set/Map no longer have an updated method mutable.Map(1 -> 2).updated(1, 3) mutable.Map(1 -> 2).clone() += 1 -> 3
collection.Set/Map no longer have + and - operations xs + 1 - 2 xs ++ Set(1) -- Set(2)
collection.Map no longer have -- operation
Seq#union is deprecated xs.union(ys) xs.concat(ys)
Stream#append is deprecated xs.append(ys) xs.lazyAppendAll(ys) v0
Iterable no longer has a sameElements operation xs1.sameElements(xs2) xs1.iterator().sameElements(xs2)
collection.breakOut no longer exists val xs: List[Int] = ys.map(f)(collection.breakOut) val xs = ys.view.map(f).to(List)
LinearSeq no longer has a companion-apply LinearSeq(1, 2, 3) List(1, 2, 3)
MapProxy, SetProxy, SynchronizedX no longer exist
SeqForwarder, MutableList, StreamView no longer exist

Other notable changes are:

  • Iterable.partition invokes iterator twice on non-strict collections and assumes it gets two iterators over the same elements. Strict subclasses override partition do perform only a single traversal

  • scala.Seq[+A] is now scala.collection.immutable.Seq[A] (this also affects varargs methods).

  • The new collections makes more use of overloading. For instance, Map.map is overloaded:

    scala> Map(1 -> "a").map
  def map[B](f: ((Int, String)) => B): scala.collection.immutable.Iterable[B]
  def map[K2, V2](f: ((Int, String)) => (K2, V2)): scala.collection.immutable.Map[K2,V2]

    Type inference has been improved so that Map(1 -> "a").map(x => (x._1 + 1, x._2)) works, the compiler can infer the parameter type for the function literal. However, using a method reference in 2.13.0-M4 (improvement are on the way for 2.13.0) does not work, and an explicit eta-expansion is necessary:

    scala> def f(t: (Int, String)) = (t._1 + 1, t._2)
scala> Map(1 -> "a").map(f)
                        ^
      error: missing argument list for method f
      Unapplied methods are only converted to functions when a function type is expected.
      You can make this conversion explicit by writing `f _` or `f(_)` instead of `f`.
scala> Map(1 -> "a").map(f _)
res10: scala.collection.immutable.Map[Int,String] = ChampHashMap(2 -> a)

Are there new collection types?

The scala-collection-contrib module provides decorators enriching the collections with new operations. You can think of this artifact as an incubator: if we get evidence that these operations should be part of the core, we might eventually move them.

The following collections are provided:

  • MultiSet (both mutable and immutable)
  • SortedMultiSet (both mutable and immutable)
  • MultiDict (both mutable and immutable)
  • SortedMultiDict (both mutable and immutable)

Are there new operations on collections?

The scala-collection-contrib module provides decorators enriching the collections with new operations. You can think of this artifact as an incubator: if we get evidence that these operations should be part of the core, we might eventually move them.

The new operations are provided via an implicit enrichment. You need to add the following import to make them available:

import strawman.collection.decorators._

The following operations are provided:

  • Seq
    • intersperse
  • Map
    • zipByKey / join / zipByKeyWith
    • mergeByKey / fullOuterJoin / mergeByKeyWith / leftOuterJoin / rightOuterJoin

Are there new implementations of existing collection types (changes in performance characteristics)?

The default Set and Map are backed by a ChampHashSet and a ChampHashMap, respectively. The performance characteristics are the same but the operation implementations are faster. These data structures also have a lower memory footprint.

mutable.Queue and mutable.Stack now use mutable.ArrayDeque. This data structure supports constant time index access, and amortized constant time insert and remove operations.

How do I cross-build my project against Scala 2.12 and Scala 2.13?

  • Compat library
  • Accept some deprecation warnings (?)
  • sbt's version-specific source folders if necessary, but should not be

Examples

New deprecations

  • ArraySeq is deprecated. 2.12 had both WrappedArray and ArraySeq, where WrappedArray has specialized subclasses for primitive arrays. ArraySeq is backed by an object array, primitives are boxed. In 2.13, WrappedArray can be used either way for primitive arrays (TODO: document how).

Collection Implementers

CanBuildFrom no longer exists - what were its uses and how can they be replaced?

How can I write generic extension methods?

How do I integrate my collection in the new design?

Read the draft document on the design of the Scala 2.13 collections: https://github.com/scalacenter/docs.scala-lang/blob/collection-strawman/_overviews/core/architecture-of-scala-collections.md

Which methods should I overload to support the “same result type” principle?

You want to add overloads to specialize a transformation operations such that they return a more specific result. Examples are:

  • map, on StringOps, when the mapping function returns a Char, should return a String (instead of an IndexedSeq),
  • map, on Map, when the mapping function returns a pair, should return a Map (instead of an Iterable),
  • map, on SortedSet, when an implicit Ordering is available for the resulting element type, should return a SortedSet (instead of a Set).

The following table lists transformation operations that might return a too wide type. You might want to overload these operations to return a more specific type.

Collection Operations
Iterable map, flatMap, collect, scanLeft, scanRight, groupMap, concat, zip, zipAll, unzip
Seq prepended, appended, prependedAll, appendedAll, padTo, patch
immutable.Seq updated
SortedSet map, flatMap, collect, zip
Map map, flatMap, collect, concat
immutable.Map updated, transform
SortedMap map, flatMap, collect, concat
immutable.SortedMap updated
Clone this wiki locally