Quelles limites la scala place-t-elle sur la «complexité acceptable» des types inférés?

120

Selon les spécifications du langage Scala :

... l'inférence de type local est autorisée pour limiter la complexité des limites inférées [des paramètres de type]. La minimalité et la maximalité des types doivent être comprises par rapport à l'ensemble des types de complexité acceptable.

En pratique, quelles sont les limites?

En outre, existe-t-il des limites différentes qui s'appliquent aux types d'expression déduits et aux limites de type de paramètre, et quelles sont ces limites?

scala type-inference

— Owen
source

ce blog a des discussions intéressantes sur ce sujet

— Jamil

Je suggérerais de poster sur la liste de diffusion en langue scala mentionnée ici: scala-lang.org/node/199

— Dave L.

Je ne suis pas sûr, mais je pense que cela signifie par exemple que nous avons une liste de chaînes et que nous y ajoutons un int. La liste immuable renvoyée est finalement de type "Any". Donc maximalité des types

— Jatin

Il s'agit en fait d'une cible mobile car différentes versions du compilateur Scala ont des limites différentes. Cela a changé et je pense que cela continuera à changer au moins dans un avenir proche à mesure que la langue continuera à se développer. Je vote cette question parce qu'elle ne peut pas recevoir de réponse telle qu'elle est actuellement énoncée.

— Kevin Sitze

@kevin Vrai en effet. Je suppose que je suis plus intéressé par scala 2.9, car il est récent mais stable. Mais je me demande combien cela changerait.

— Owen

Lors de la déduction de types, le compilateur a souvent besoin de calculer la limite inférieure (LUB) d'une liste de types. Par exemple, le type de if (cond) e1 else e1est le LUB des types de e1et e1.

Ces types peuvent devenir assez volumineux, par exemple, essayez ceci dans un REPL:

:type Map(1 -> (1 to 10), 2 -> (1 to 10).toList)
scala.collection.immutable.Map[Int,scala.collection.immutable.Seq[Int] with scala.collection.AbstractSeq[Int] with Serializable{def reverse: scala.collection.immutable.Seq[Int] with scala.collection.AbstractSeq[Int]{def reverse: scala.collection.immutable.Seq[Int] with scala.collection.AbstractSeq[Int]; def dropRight(n: Int): scala.collection.immutable.Seq[Int] with scala.collection.AbstractSeq[Int]; def takeRight(n: Int): scala.collection.immutable.Seq[Int] with scala.collection.AbstractSeq[Int]; def drop(n: Int): scala.collection.immutable.Seq[Int] with scala.collection.AbstractSeq[Int]; def take(n: Int): scala.collection.immutable.Seq[Int] with scala.collection.AbstractSeq[Int]}; def dropRight(n: Int): scala.collection.immutable.Seq[Int] with scala.collection.AbstractSeq[Int]{def reverse: scala.collection.immutable.Seq[Int] with scala.collection.AbstractSeq[Int]; def dropRight(n: Int): scala.collection.immutable.Seq[Int]...

Ce commit a introduit des vérifications de cohérence pour limiter la profondeur de ces types inférés.

Il y a eu des travaux récents pour intégrer le processus de compilation pour détecter les types inférés qui prennent beaucoup de temps à calculer, et suggérer des endroits où une annotation de type explicite pourrait être prudente.

— rétronyme
source