Hut, hut, hike! Yikes!

[som-snytt]

This sounds like a quarterback's calls in American football. There's also a pun on "Double or Nothing" in there.

scala> val right1 = Right(1)   : Right[Double, Int]
right1: Right[Double,Int] = Right(1)

scala> val left23 = Left(23.0) : Left[Double, Int]
left23: Left[Double,Int] = Left(23.0)

scala> val left42 = Left(42.0)
left42: scala.util.Left[Double,Nothing] = Left(42.0)

scala> for {
     | x <- right1
     | y <- left42
     | z <- left23
     | } yield x + y + z
res0: scala.util.Either[Double,String] = Left(42.0)

[demobox]

Thanks for this one, @som-snytt! Just to clarify, is it the result type you're referring to here? I'm assuming this is the "new" right-biased Either, incidentally...

[som-snytt]

Someone noticed the example code didn't compile, and more code and words, and maybe code words, was deemed useful. I just wound up more confused, or at least less inclined to exploit the feature.

 *  // Guard expressions are not supported:
 *  for {
 *    i <- right1
 *    if i > 0
 *  } yield i
 *  // error: value withFilter is not a member of Right[Double,Int]
 *
 *  // Similarly, refutable patterns are not supported:
 *  for (x: Int <- right1) yield x
 *  // error: value withFilter is not a member of Right[Double,Int]
 *  }}}
 *
 *  Since `for` comprehensions use `map` and `flatMap`, the types
 *  of function parameters used in the expression must be inferred.
 *  These types are constrained by the `Either` values. In particular,
 *  because of right-biasing, `Left` values may require an explicit
 *  type argument for type parameter `B`, the right value. Otherwise,
 *  it might be inferred as `Nothing`.
 *
 *  {{{
 *  for {
 *    x <- left23
 *    y <- right1
 *    z <- left42  // type at this position: Either[Double, Nothing]
 *  } yield x + y + z
 *  //            ^
 *  // error: ambiguous reference to overloaded definition,
 *  // both method + in class Int of type (x: Char)Int
 *  // and  method + in class Int of type (x: Byte)Int
 *  // match argument types (Nothing)
 *
 *  for (x <- right2 ; y <- left23) yield x + y  // Left(23.0)
 *  for (x <- right2 ; y <- left42) yield x + y  // error
 *
 *  for {
 *    x <- right1
 *    y <- left42  // type at this position: Either[Double, Nothing]
 *    z <- left23
 *  } yield x + y + z
 *  // Left(42.0), but unexpectedly a `Either[Double,String]`

[demobox]

Ah, so this is good ol' any2stringadd to the rescue (?):

        private[this] val res0: scala.util.Either[Double,String] = $line18.$read
.$iw.$iw.right1.flatMap[Double, String](((x: Int) => $line19.$read.$iw.$iw.left4
2.flatMap[Double, String](((y: Nothing) => $line20.$read.$iw.$iw.left23.map[Stri
ng](((z: Int) => scala.Predef.any2stringadd[Int](x).+(y).+(z)))))));

So the Nothing here actually "saves" us from ambiguity in:

val right1 = Right(1)   : Right[Double, Int]
val left23 = Left(23.0)
for {
     x <- right1
     y <- left23
     } yield x + y
...
<console>:17: error: ambiguous reference to overloaded definition,
both method + in class Int of type (x: Char)Int
and  method + in class Int of type (x: Byte)Int
match argument types (Nothing)
            } yield x + y
                      ^

Do you have any thoughts on how the additional + z at the end (where z is an Int) allows the compiler to resolve the ambiguity it is unable to resolve in the latter example? Put differently, why does the latter example not also result in an Either[Double, String], with the expression yielded being scala.Predef.any2stringadd[Int](x).+(y)?

Adding an integer constant does seem to allow that to happen:

scala> for {
     |      x <- right1
     |      y <- left23
     |      } yield x + y + 0
...
res2: scala.util.Either[Double,String] = Left(23.0)

[demobox]

@som-snytt Can you think of any operators other than + (with the help of any2stringadd that could cause this?

[som-snytt]

You can also see it this way: for (x<-left23;y<-right1;z<-left42) yield x+z+y which is the example with z and y switched.

The arg to the innermost map is Nothing because left42 is double or nothing.

Then you need to make x.+(???)+.(y) work. The ordinary overloaded method is ambiguous, so it looks for an implicit that is not ambiguous. I didn't look at -Ytyper-debug. It's not that interesting.

[demobox]

Then you need to make x.+(???)+.(y) work. The ordinary overloaded method is ambiguous, so it looks for an implicit that is not ambiguous.

That's what I had assumed, too - thanks for the details. My question was why it doesn't successfully "look for an implicit that is not ambiguous" when it's simply trying to solve x.+(???)?

But indeed perhaps not one for a dive into the realms of -Ytyper-debug? ;-)