New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mutable.IndexedSeq.view.map returns collection.SeqView #4190
Comments
Imported From: https://issues.scala-lang.org/browse/SI-4190?orig=1 |
@jsuereth said: |
@soc said: |
@jrudolph said: |
@jrudolph said: For some reason for this line val y: IndexedSeq[String] = collection.mutable.ArrayBuffer(1,2,3).view.map[String, IndexedSeq[String]](_ + "0") this is inferred in typer: val y: IndexedSeq[String] = scala.collection.mutable.ArrayBuffer.apply[Int](1, 2, 3).view.map[String, IndexedSeq[String]](((x$1: Int) => x$1.+("0")))(mutable.this.IndexedSeq.canBuildFrom[String]); so it is using a CanBuildFrom from IndexedSeq which isn't what usually happens with views where a call like this would fail because of a missing CBF. I don't really understand what's going on in the collections </embarassing confession> but is it possible that mutable.IndexedSeqView is just missing the usual boilerplate for |
@jsuereth said: Here's a relevant snippet with the types inferred: scala> val x = collection.mutable.ArrayBuffer(1,2,3)
x: scala.collection.mutable.ArrayBuffer[Int] = ArrayBuffer(1, 2, 3)
scala> x.view
res1: scala.collection.mutable.IndexedSeqView[Int,scala.collection.mutable.ArrayBuffer[Int]] = SeqView(...)
scala> res1 map (_ + "0")
res2: scala.collection.SeqView[String,scala.collection.mutable.Seq[_]] = SeqViewM(...) We loose the IndexedSeqView after a map, which tells me either (a) it's not overridden (likely) or (b) it's missing an appropriate CanBuildFrom. If the answer is (a), I'll have to dig further. This may be a limitation on IndexedSeqView that after a transformation operation, you shouldn't treat it as an IndexedSeq anymore. |
@jsuereth said (edited on May 9, 2012 12:57:50 PM UTC): (1) mutable.IndexedViewSeq will actually manipulate the underlying collection at the view given. val x = collection.mutable.ArrayBuffer(1,2,3)
val y = x.view map (_ + "0")
val z = y.update(0, "O NOES") (3) the "indexed" part of the type implies fast indexed lookup. That's not the case for views that have transformations. It may be confusing to drop from an mutable.IndexSeqView to SeqView, but given the three points above, I'm thinking we have "correct" behavior here. I'll try to flush out all the ClassCastExceptions and make sure you can't accidentally assign to IndexedSeq once you loose the "Indexed"-ness. |
@jrudolph said: |
@jsuereth said: SO yes. You're no longer a mutable.IndexedSeq after a map/flatMap/etc. |
@jrudolph said: |
@JamesIry said: |
@adriaanm said: |
@Ichoran said: |
@Ichoran said: scala> Array(1, 2, 3, 4).view
res60: scala.collection.mutable.IndexedSeqView[Int,Array[Int]] = SeqView(...)
OK
scala> Array(1, 2, 3, 4).view.map{x => println(x); x}
res61: scala.collection.SeqView[Int,Array[Int]] = SeqViewM(...)
OK
scala> Array(1, 2, 3, 4).view.map{x => println(x); x}.map{x => println(x); x}
res62: Seq[Int] = SeqViewMM(...)
WTF? Why Seq?
After that point I can't call a force method. But I want to get some results so lets try:
scala> Array(1, 2, 3, 4).view.map{x => println(x); x}.map{x => println(x); x}.take(1).toList
1
1
res64: List[Int] = List(1)
OK..
scala> Array(1, 2, 3, 4).view.map{x => println(x); x}.map{x => println(x); x}.take(1).toArray
1
1
1
1
res65: Array[Int] = Array(1)
Double view evaluation! Note that double view evaluation isn't forbidden by the contract, but views should perhaps be a little smarter about the choice of algorithm |
Iurii Gazin (archeg) said: "abc".view.updated(0, 'A') But it returns Seq, the same as in previous comment. It looks like it's missing appropriate CanBuildFrom. Seq('a', 'b', 'c').view.updated(0, 'A') works fine. It looks very similar to some of the code reported above, but this time it is about immutable structure. Scala 2.11.2 |
@Ichoran said: I recommend punting until 2.13, @adriaanm @szeiger (at which point I may have time to get my tentative fixes in). |
likely fixed in strawman. leaving it on M4 milestone so we can check it once strawman lands |
The view type herarchy is much more shallow in 2.13, which mean we lose some view functionality, but are no longer exposed to bugs like those in this ticket. |
=== What steps will reproduce the problem (please be specific and use wikiformatting)? ===
This code compiles but produces a
ClassCastException
in the last line:=== What is the expected behavior? ===
A compiler error or working code.
=== What versions of the following are you using? ===
The text was updated successfully, but these errors were encountered: