2013-07-02 12 views
24

Załóżmy, że mam ten jednowartościowy Klasa:Nowe zachowanie desugaring w Scala 2.10.1

case class Foo[A](xs: List[A]) { 
    def map[B](f: A => B) = Foo(xs map f) 
    def flatMap[B](f: A => Foo[B]) = Foo(xs flatMap f.andThen(_.xs)) 
    def withFilter(p: A => Boolean) = { 
    println("Filtering!") 
    Foo(xs filter p) 
    } 
} 

Poniżej jest z sesji 2.10.0 REPL:

scala> for { (a, b) <- Foo(List(1 -> "x")) } yield a 
res0: Foo[Int] = Foo(List(1)) 

i tu jest to samo w 2,10 .1:

scala> for { (a, b) <- Foo(List(1 -> "x")) } yield a 
Filtering! 
res0: Foo[Int] = Foo(List(1)) 

Jest to całkowicie nieoczekiwane (dla mnie) i prowadzi do szczególnie mylących błędów w przypadkach, gdy wymagane jest filtrowanie istnieją dodatkowe ograniczenia (takie jak Scalaz's \/ or EitherT).

Nie mogłem znaleźć żadnej dyskusji na temat tej zmiany w 2.10.1 release notes. Czy ktoś może wskazać, gdzie i dlaczego wprowadzono to nowe działanie powodujące desugaring?

Odpowiedz

16

Ta historia jest bardziej złożona, a tak naprawdę jest to regresja 2.10.0, która została tam podłączona.

Zachowanie "no-withFilter" zostało wprowadzone w c82ecab, a z powodu rzeczy takich jak SI-6968, zostało to częściowo cofnięte #1893. Dalsze adaptacje następnie (SI-6646, SI-7183)

zdanie wynos szukasz jest:

Parser nie można zakładać, że wzór (a, b) będzie pasował, jak wynika z . isInstanceOf [Tuple2] nie może być statycznie znany dopiero po typerie .