Details

Type: Improvement

Status: Closed

Priority: Minor

Resolution: Fixed

Affects Version/s: None

Fix Version/s: Scala 2.11.0M8

Component/s: Misc Compiler

Labels:
Description
1) implicit search and implicit conversion search treat undetermined type parameters differently
2) constraints are carried over in an adhoc way (by tracking undetermined type parameters in the context)
> this works for influencing the inference of type parameters by "later aspects" of the expression, but not for inferring implicit values, since these cannot be left undetermined while type checking an expression (see SI4653)
the idea of generalising tracking of undetermined implicit types (type parameters)/implicit values and their constraints could drive the solution for SI3340, SI3346, SI2781 and SI3270
Issue Links
 blocks

SI5107 Implicit is not considered if method in question has a(n unused) type parameter
 Open

SI2673 zipped does not work for arrays
 Closed

SI3270 Implicit conversion involving return type Pair[A,B] or TupleX[A,B,C,...] with input view bounds doesn't work
 Closed

SI4653 Problem inferring type parameter with Manifest context bound
 Closed

SI3340 implicit search should resolve ambiguities by fully resolving transitively required implicit arguments
 Open

SI5592 Metabug: Omitting nonambiguous implicit conversions should be valid
 Open

SI3346 the implicit arguments of implicit conversions do not guide type inference
 Closed

SI2781 type inference constraints should be carried along during search for chained implicits
 Closed
I was wondering: can available implicits be modeled as constraints? Also, could constraint solving be done once per statement, instead of on each invocation (as currently specified)?
The more I run into problems, the more it seems that even more should be delegated to a constraint solver (see also SI5298).