Uploaded image for project: 'Scala Programming Language'
  1. Scala Programming Language
  2. SI-5441

traits Map and Set do not match mutable versions

    Details

    • Type: Bug
    • Status: CLOSED
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: Scala 2.9.1
    • Fix Version/s: Scala 2.10.3-RC1
    • Component/s: None
    • 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>
      

        Attachments

          Activity

          Hide
          prokopec 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
          prokopec 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
          extempore Paul Phillips added a comment -

          Regardless, it's the expected behavior.

          Show
          extempore Paul Phillips added a comment - Regardless, it's the expected behavior.
          Hide
          prokopec 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
          prokopec 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
          extempore 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
          extempore 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
          extempore 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
          extempore 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
          man 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
          man 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
          extempore 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
          extempore 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
          jamesiry 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
          jamesiry 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
          retronym 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
          retronym 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:
              man Felix Dietze
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: