Scala Programming Language
  1. Scala Programming Language
  2. SI-5441

traits Map and Set do not match mutable versions

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: Scala 2.9.1
    • Fix Version/s: Scala 2.10.3-RC1
    • Component/s: Collections
    • Labels:
      None
    • Environment:

      Scala 2.9.1

      Description

      I'm wondering why collection.mutable.Seq can be of type Seq while mutable.Map and mutable.Set cannot be of type Map and Set. Is that the expected behavior or a Bug?

      Welcome to Scala version 2.9.1.final (Java HotSpot(TM) Client VM, Java 1.6.0_26).
      Type in expressions to have them evaluated.
      Type :help for more information.
      
      scala> val a:Seq[Int]     = collection.mutable.Seq[Int]()
      a: Seq[Int] = ArrayBuffer()
      
      scala> val b:Set[Int]     = collection.mutable.Set[Int]()
      <console>:7: error: type mismatch;
       found   : scala.collection.mutable.Set[Int]
       required: scala.collection.immutable.Set[Int]
             val b:Set[Int]     = collection.mutable.Set[Int]()
                                                             ^
      
      scala> val c:Map[Int,Int] = collection.mutable.Map[Int,Int]()
      <console>:7: error: type mismatch;
       found   : scala.collection.mutable.Map[Int,Int]
       required: scala.collection.immutable.Map[Int,Int]
             val c:Map[Int,Int] = collection.mutable.Map[Int,Int]()
                                                                 ^
      
      scala>
      

        Activity

        Hide
        Aleksandar Prokopec added a comment -

        that's because there is a type alias in Predef saying that `scala.Set` == `scala.collection.immutable.Set`, and not `scala.collection.Set`. I don't know why things were done this way.

        Show
        Aleksandar Prokopec added a comment - that's because there is a type alias in Predef saying that `scala.Set` == `scala.collection.immutable.Set`, and not `scala.collection.Set`. I don't know why things were done this way.
        Hide
        Paul Phillips added a comment -

        Regardless, it's the expected behavior.

        Show
        Paul Phillips added a comment - Regardless, it's the expected behavior.
        Hide
        Aleksandar Prokopec added a comment -

        I always wondered about this one. Do we have the reasoning why this is the expected behaviour documented somewhere?

        Show
        Aleksandar Prokopec added a comment - I always wondered about this one. Do we have the reasoning why this is the expected behaviour documented somewhere?
        Hide
        Paul Phillips added a comment -

        Reopening because I just noticed the collection package object tells a completely different (false) story.

        
         * The most common way to create a collection is to use the companion objects as factories.
         * Of these, the three most common
         * are [[scala.collection.immutable.Seq]], [[scala.collection.immutable.Set]], and [[scala.collection.immutable.Map]].  Their
         * companion objects are all available
         * as type aliases the either the [[scala]] package or in `scala.Predef`, and can be used
         * like so:
         * {{{
         * scala> val seq = Seq(1,2,3,4,1)
         * seq: Seq[Int] = List(1, 2, 3, 4, 1)
         *
         * scala> val set = Set(1,2,3,4,1)
         * set: scala.collection.immutable.Set[Int] = Set(1, 2, 3, 4)
         *
         * scala> val map = Map(1 -> "one",2 -> "two", 3 -> "three",2 -> "too")
         * map: scala.collection.immutable.Map[Int,java.lang.String] = Map((1,one), (2,too), (3,three))
         * }}}
         *
         * It is also typical to use the [[scala.collection.immutable]] collections over those
         * in [[scala.collection.mutable]]; The types aliased in the [[scala]] package and
         * the `scala.Predef` object are the immutable versions.
        
        Show
        Paul Phillips added a comment - Reopening because I just noticed the collection package object tells a completely different (false) story. * The most common way to create a collection is to use the companion objects as factories. * Of these, the three most common * are [[scala.collection.immutable.Seq]], [[scala.collection.immutable.Set]], and [[scala.collection.immutable.Map]]. Their * companion objects are all available * as type aliases the either the [[scala]] package or in `scala.Predef`, and can be used * like so: * {{{ * scala> val seq = Seq(1,2,3,4,1) * seq: Seq[Int] = List(1, 2, 3, 4, 1) * * scala> val set = Set(1,2,3,4,1) * set: scala.collection.immutable.Set[Int] = Set(1, 2, 3, 4) * * scala> val map = Map(1 -> "one",2 -> "two", 3 -> "three",2 -> "too") * map: scala.collection.immutable.Map[Int,java.lang.String] = Map((1,one), (2,too), (3,three)) * }}} * * It is also typical to use the [[scala.collection.immutable]] collections over those * in [[scala.collection.mutable]]; The types aliased in the [[scala]] package and * the `scala.Predef` object are the immutable versions.
        Hide
        Paul Phillips added a comment -

        And I don't remember anything definitive about why it's this way, only that it has always been thus. Arrays were likely a factor in the origins - it probably just made it too inconvenient to deal with them.

        Show
        Paul Phillips added a comment - And I don't remember anything definitive about why it's this way, only that it has always been thus. Arrays were likely a factor in the origins - it probably just made it too inconvenient to deal with them.
        Hide
        Felix Dietze added a comment - - edited

        This is marked as fixed, but it is still present in 2.10.0-RC1:

        Welcome to Scala version 2.10.0-RC1 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_09).
        Type in expressions to have them evaluated.
        Type :help for more information.

        scala> val a:Seq[Int] = collection.mutable.Seq[Int]()
        a: Seq[Int] = ArrayBuffer()

        scala> val b:Set[Int] = collection.mutable.Set[Int]()
        <console>:8: error: type mismatch;
        found : scala.collection.mutable.Set[Int]
        required: scala.collection.immutable.Set[Int]
        val b:Set[Int] = collection.mutable.Set[Int]()
        ^

        scala> val c:Map[Int,Int] = collection.mutable.Map[Int,Int]()
        <console>:8: error: type mismatch;
        found : scala.collection.mutable.Map[Int,Int]
        required: scala.collection.immutable.Map[Int,Int]
        val c:Map[Int,Int] = collection.mutable.Map[Int,Int]()
        ^

        Show
        Felix Dietze added a comment - - edited This is marked as fixed, but it is still present in 2.10.0-RC1: Welcome to Scala version 2.10.0-RC1 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_09). Type in expressions to have them evaluated. Type :help for more information. scala> val a:Seq [Int] = collection.mutable.Seq [Int] () a: Seq [Int] = ArrayBuffer() scala> val b:Set [Int] = collection.mutable.Set [Int] () <console>:8: error: type mismatch; found : scala.collection.mutable.Set [Int] required: scala.collection.immutable.Set [Int] val b:Set [Int] = collection.mutable.Set [Int] () ^ scala> val c:Map [Int,Int] = collection.mutable.Map [Int,Int] () <console>:8: error: type mismatch; found : scala.collection.mutable.Map [Int,Int] required: scala.collection.immutable.Map [Int,Int] val c:Map [Int,Int] = collection.mutable.Map [Int,Int] () ^
        Hide
        Paul Phillips added a comment -

        I believe what was fixed was the documentation. Although the subject is presently under discussion, for now it is still the expected behavior and therefore "not a bug."

        Show
        Paul Phillips added a comment - I believe what was fixed was the documentation. Although the subject is presently under discussion, for now it is still the expected behavior and therefore "not a bug."
        Hide
        James Iry added a comment -

        2.10.2 is about to be cut. Kicking down the road and un-assigning to foster work stealing.

        Show
        James Iry added a comment - 2.10.2 is about to be cut. Kicking down the road and un-assigning to foster work stealing.
        Hide
        Jason Zaugg added a comment -

        Reclosing for the documentation fix. Changing the type alias would be incredibly hard to do in a compatible manner, and almost need a SIP.

        Show
        Jason Zaugg added a comment - Reclosing for the documentation fix. Changing the type alias would be incredibly hard to do in a compatible manner, and almost need a SIP.

          People

          • Assignee:
            Unassigned
            Reporter:
            Felix Dietze
          • Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development