0

joinLeft is defined as:

abstract class Either[+A, +B]

def joinLeft[A1 >: A, B1 >: B, C](implicit ev: A1 <:< Either[C, B1]):
    Either[C, B1] = this match {
    case Left(a)  => a
    case Right(b) => Right(b)
}
  • With the known A and B, we need an implicit ev: A1 <:< Either[C, B1] that
    1. satisfies constraint A1 >: A, B1 >: B.
    2. reifies A1 <: Either[C, B1]

  • For that we'll need implicit conforms[A1] and conforms[Either[C, B1]]

If I'm still right until now, there seem to me many choices for A1 and B1 as long as they are beyond lower bounds A and B. So I would like to know how scala gives us A1 and Either[C, B1](and what they are) so that we get implicit conforms to facilitate <:< to do its job of asserting A1 <: Either[C, B1].

P.S.
I think this question is somewhat related to my another one "joinLeft [A1 >: A, B1 >: B, C]… why are type constraint A1 >: A and B1>: B necessary?". I would appreciate if anyone can also take a look at it.

Community
  • 1
  • 1
cfchou
  • 1,239
  • 1
  • 11
  • 25

1 Answers1

1

You are right, there are many choices. In general, type inference on generic method uses the arguments to determine the value of the generic parameter

def myMethod[A](aList:List[A])

However, this is not the only way to use type inference of generic arguments. Notably, type parameters can be :

  • explicit
  • determined using the expected result type

In this case, as the generic type parameter cannot be determined from the arguments (because there are no explicit arguments), you typically assign the result of the method to a typed variable, or you use it at the end of a method with explicit return type.

You might ask yourself how A1 will be solved and this is a very interesting question. In fact A1 is not present in the input type, nor in the output type. What is it useful for?

The answer is in the following definition, coming from Predef.scala

@implicitNotFound(msg = "Cannot prove that ${From} <:< ${To}.")
  sealed abstract class <:<[-From, +To] extends (From => To) with Serializable

Since the <:< is contravariant in From the method

def joinLeft[B1 >: B, C](implicit ev: A <:< Either[C, B1]):
    Either[C, B1] = this match {
    case Left(a)  => a
    case Right(b) => Right(b)
}

won't handle correctly subclassing on A. That's why you need an extra generic type parameter A1, which is resolved by the Scala compiler by using the A1 which gives the implicit with the highest priority.

Edmondo
  • 19,559
  • 13
  • 62
  • 115
  • Could you provide an example where a missing `A1 >: A` leads to a type error/wrong inferred type? – kiritsuku Apr 15 '13 at 15:31
  • @Edmondo1984 "which is resolved by the Scala compiler by using the A1 which ...", did you mean "by using A which ..."? – cfchou Apr 15 '13 at 16:13
  • no, A is a type parameter of Either[A,B] so it has not to be resolved. In the context of the method joinLeft A and B are fixed – Edmondo Apr 15 '13 at 16:15
  • I assume `A1` will be resolved to be the type of the thing plugged into `ev.apply(x: A1): Either[C, B1]`, which would be the type of `a` or the type of `Right(b)`. Did you mean that the compiler chooses one of them that makes the implicit with the higher priority? If so, could you elaborate on what the criterion is? – cfchou Apr 15 '13 at 17:03
  • Exactly. The implicit priority rules are a part of the scala language specification – Edmondo Apr 15 '13 at 17:31
  • I don't see how `A1` is necessary because of the contravariant nature of FunctionX parameters, but I may be wrong, that's why I asked for an example. – kiritsuku Apr 15 '13 at 20:23
  • you are probably more experienced than me. That's the only reason why I could see the need for an extra A1 – Edmondo Apr 15 '13 at 20:49