The type checking happens in two steps:
- Check whether parameter untupling is feasible
- Adapt the function and type check it
Suppose a function
f of the form
(p1, ..., pn) => e (where
n > 1), with
p1, ..., pn as parameters and
e as function body.
If the expected type for checking
f is a fully defined function type of the form
TupleN[T1, ..., Tn] => R (or an equivalent SAM-type), where each type
Ti fits the corresponding parameter
f is feasible for parameter untupling with the expected type
TupleN[T1, ..., Tn] => R.
Ti fits a parameter
pi if one of the following two cases is
picomes without a type, i.e. it is a simple identifier or
piis of the form
Ti <: Ui.
Parameter untupling composes with eta-expansion. That is, an n-ary function generated by eta-expansion can in turn be adapted to the expected type with parameter untupling.
If the function
(p1, ..., pn) => e
is feasible for parameter untupling with the expected type
TupleN[T1, ..., Tn] => Te, then continue to type check the following adapted function
(x: TupleN[T1, ..., Tn]) => def p1: T1 = x._1 ... def pn: Tn = x._n e
with the same expected type.
Code like this could not be written before, hence the new notation is not ambiguous after adoption.
It is possible that someone has written an implicit conversion from
(T1, ..., Tn) => R to
TupleN[T1, ..., Tn] => R for some
n. Such a conversion is now only useful for general conversions of function values, when parameter untupling is not applicable. Some care is required to implement the conversion efficiently. Obsolete conversions could be detected and fixed by
For more information, see Issue #897.