Multiple lower type bounds in Scala

Question

I noticed that tuple.productIterator always returns an Iterator[Any] an wondered if it's not possible to set multiple lower bounds (so it could be an Iterator of the lowest common super type).

I tried and searched a bit, but only found this question for multiple upper bounds.

This is my test on how to define the the type of the iterator:

def f[A,B](a:A, b:B) = List(a,b)
// return type is List[Any]

def f[A,B, T >: A "and" T >: B](a:A, b:B) = List[T](a,b)
// doesn't compile, but
//  f(1, true) should give a List[AnyVal] and
//  f("x", "y") a List[String]

Is this a limitation of the JVM?

---

Edit: Here's a slightly bigger example which doesn't seem to be solvable using IttayD approach when T should be defined in the method:

class Foo[A, B](a: A, b: B) {
  def f[T >: A] = List[T](a) // works
  def g[T >: A "and" T >: B] = List[T](a) // doesn't work
}

Answer 1

It sounds like what you need is an HList: http://apocalisp.wordpress.com/2010/07/06/type-level-programming-in-scala-part-6a-heterogeneous-list%C2%A0basics/

To answer the specific question:

scala> def f[T, A <: T,B <: T](a:A, b:B) = List[T](a,b)
f: [T, A <: T, B <: T](a: A, b: B)List[T]

scala> f(1, true)
res0: List[AnyVal] = List(1, true)

scala> f("x", "y")
res1: List[java.lang.String] = List(x, y)

Answer 2

For the simple case where A and B are bound by the compiler as the same time as T, IttayD's answer works fine:

def f[T, A <: T,B <: T](a:A, b:B) = List[T](a,b)

When A and B are already bound as in your class Foo[A, B] example, you need to introduce temporary dummy variables to have the compiler do this job:

class Foo[A, B](a: A, b: B) {
  def g[T, A1 >: A <: T, B1 >: B <: T] = List[T](a: A1, b: B1)
}

(For the sake of clarity: A1 >: A <: T means that type A1 must be a supertype of A and a subtype of T, and not that A is a subtype of both A1 and T.)

A1 and B1 are here for the sole purpose of inferring a correct type for T. If the compiler has to infer them, they will resolve to A1 = A and B1 = B, and then T as the most specific type which is a superclass of both A and B.

One thing that the compiler doesn't realize, though, is that, by transitivity, we have both T >: A and T >: B, which follows directly from the constraints with respect to A1 and B1. We need to help out with the type ascriptions.

Now, Product#productIterator could not use this technique, as it's defined in a place where we don't even know A and B, or indeed how many type parameters there are in the concrete subclass.