¿Por qué el conjunto inmóvil de Scala no es covariante en su tipo?

Question

EDITAR: Re-escrito esta pregunta basada en respuesta original

La clase scala.collection.immutable.Set no es covariante en su parámetro de tipo. ¿Por qué es esto?

import scala.collection.immutable._ 

def foo(s: Set[CharSequence]): Unit = { 
    println(s) 
} 

def bar(): Unit = { 
    val s: Set[String] = Set("Hello", "World"); 
    foo(s); //DOES NOT COMPILE, regardless of whether type is declared 
      //explicitly in the val s declaration 
} 

Answer 1

Set es invariable en su parámetro de tipo debido al concepto detrás de conjuntos como funciones. Las firmas siguientes deben aclarar las cosas un poco:

trait Set[A] extends (A=>Boolean) { 
    def apply(e: A): Boolean 
} 

Si Set fueron covariante en A, el método apply sería incapaz de tomar un parámetro de tipo A debido a la contravarianza de funciones. Set podría ser potencialmente contravariant en A, pero esto también provoca problemas cuando se quiere hacer cosas como esta:

def elements: Iterable[A] 

En resumen, la mejor solución es mantener las cosas invariables, incluso para la estructura de datos inmutables. Notará que immutable.Map también es invariable en uno de sus parámetros de tipo.

Answer 2

EDITAR: para cualquiera que se pregunte por qué esta respuesta parece un poco fuera de tema, esto se debe a que (el interrogador) he modificado la pregunta.

La inferencia de tipo de Scala es lo suficientemente buena como para descubrir que desea secuencias de caracteres y no cadenas en algunas situaciones. En particular, las siguientes obras para mí en 2.7.3:

import scala.collections.immutable._ 
def findCharSequences(): Set[CharSequence] = Set("Hello", "World") 

cuanto a cómo crear directamente immutable.HashSets: no. Como una optimización de implementación, inmutable.HashSets de menos de 5 elementos no son en realidad instancias de inmutable.HashSet. Son EmptySet, Set1, Set2, Set3 o Set4. Estas clases subclase inmutable.Set, pero no inmutable.HashSet.

Answer 3

en http://www.scala-lang.org/node/9764 Martin Odersky escribe:

"Sobre la cuestión de conjuntos, creo que el no-varianza se deriva también de las implementaciones de conjuntos comunes se implementan como tablas hash, que son matrices no variante del. tipo de llave. Acepto que es una irregularidad ligeramente molesta ".

Por lo tanto, parece que todos nuestros esfuerzos para construir una razón de principio para este eran :-) equivocada