Restrict to cases where there is an expected type

Author: Sporarum

content/polymorphic-eta-expansion.md

@@ -21,12 +21,11 @@ permalink: /sips/:title.html
 - For returning readers, a quick reminder of what the proposal is about. -->
 
 We propose to extend eta-expansion to polymorphic methods. 
-This means automatically transforming polymorphic methods into corresponding polymorphic functions, for example:
+This means automatically transforming polymorphic methods into corresponding polymorphic functions when required, for example:
 
 ~~~ scala
 def f1[A](x: A): A = ???
 val v1_1: [B] => B => B = f1 // f1 becomes [B'] => (y: B') => f1[B'](y)
-val v1_2                = f1 // f1 becomes [A'] => (x': A') => f1[A'](x')
 ~~~
 
 Returning readers, for a quick glance at a wide array of examples illustrated like the above, go to [High-level overview](#high-level-overview).
@@ -201,16 +200,13 @@ In the following `id'` means a copy of `id` with a fresh name, and `//reminder:`
 ~~~ scala
 def f1[A](x: A): A = ???
 val v1_1: [B] => B => B = f1 // f1 becomes [B'] => (y: B') => f1[B'](y)
-val v1_2                = f1 // f1 becomes [A'] => (x': A') => f1[A'](x')
 
 def f2[A]: A => A = ???
 val v2_1: [B] => B => B = f2 // f2 becomes [B'] => (y: B') => f2[B'](y)
-val v2_2                = f2 // f2 becomes f2[Any]
 
 type F[C] = C => C
 def f3[A]: F[A] = ???
 val v3_1: [B] => B => B = f3 // f3 becomes [B'] => (y: B') => f3[B'](y)
-val v3_1:               = f3 // f3 becomes f3[Any]
 
 //reminder:
 val vErr: [B] => B    = ??? // error: polymorphic function types must have a value parameter
@@ -222,22 +218,18 @@ extension (x: Int)
   def extf1[A](x: A): A = ???
 
 val extv1_1: [B] => B => B = extf1(4) // extf1(4) becomes [B'] => (y: B')  => extf1(4)[B'](y)
-val extv1_2                = extf1(4) // extf1(4) becomes [A'] => (x': A') => extf1(4)[A'](x')
 
 val extv1_3: Int => [B] => B => B = extf1 // extf1 becomes (i: Int) => [B'] => (y: B')  => extf1(i)[B'](y)
-val extv1_4                       = extf1 // extf1 becomes (i: Int) => [A'] => (x': A') => extf1(i)[A'](x')
 ~~~
 
 #### Implicit parameters:
 ~~~ scala
 def uf1[A](using x: A): A = ???
 val vuf1_1: [B] => B ?=> B = uf1 // uf1 becomes [B'] => (y: B') ?=> uf1[B']
-val vuf1_1:                = uf1 // uf1 becomes uf1[X](using x) where X and x are given by type and term inference
 
 
 def uf2[A]: A = ???
 val vuf2: [B] => B ?=> B = uf2 // uf2 becomes [B'] => (y: B') ?=> uf2[B']
-val vuf2:                = uf2 // uf2 becomes uf2[X] where X is given by type inference
 
 //reminder:
 val get: (String) ?=> Int = 22 // 22 becomes (s: String) ?=> 22
@@ -270,9 +262,9 @@ val voly: Int => [T] => T => T = poly
 
 As this feature only provides a shortcut to express already definable objects, the only impacted area is the type system.
 
-When typing a polymorphic method `m` there are three cases to consider:
+When typing a polymorphic method `m` there are two cases to consider:
 
-#### With expected type
+#### Polymorphic expected type
 If the expected type is a polymorphic function taking `[T_1 <: U_1 >: L_1, ..., T_n <: U_n >: L_n]` as type parameters, `(A_1, ..., A_k)` as term parameters and returning `R`, we proceed as follows:
 
 Note: Polymorphic functions always take term parameters (but `k` can equal zero if the clause is explicit: `[T] => () => T`).
@@ -297,7 +289,7 @@ Note: Polymorphic functions always take term parameters (but `k` can equal zero
 * 1. If it succeeds, the above is the created tree.
 * 2. If it fails, go to [Default](#Default).
 
-At 3.2. if the cause of the error is such that [Default](#Default) will never succeed, we might return that error directly, this is at the discretion of the implementation, to make errors as clear as possible.
+At 3.ii. if the cause of the error is such that [Non-polymorphic expected type](#non-polymorphic-expected-type) will never succeed, we might return that error directly, this is at the discretion of the implementation, to make errors as clear as possible.
 
 Note: Type checking will be in charge of overloading resolution, as well as term inference, so the following will work:
 ~~~ scala
@@ -327,43 +319,7 @@ val voo: [T] => T => [U] => U => (T, U) = foo
 // [T'] => (t: T') => [U'] => (u: U') => foo[T'](t)[U'](u)
 ~~~
 
-#### Without expected type
-
-<!-- TODO: Think more about overloading
-
-If there is no expected type, let `ms` be all the overloaded variants of `m` which take at least one explicit parameter clause.
-
-If `ms` contains no variants, go to [Default](#Default).
-If it contains more than one variant, throw an overloading error.
-
-If `ms` contains exactly one variant, then it is expanded as follows:
--->
-
-`m` has to contain at least one explicit term clause before the return type or the next type clause.
-<details>
-  <summary>Note</summary>
-  Since the only way to create multiple type clause is with extension methods, and since they force an explicit clause, this condition is currently equivalent to "`m` contains explicit term parameters".
-  The stricter wording was chosen to already accommodate [SIP-47 - Clause Interleaving](https://github.com/scala/improvement-proposals/pull/47).
-</details>
-
-If `m` doesn't satisfy the above condition, go to [Default](#Default), otherwise:
-
-Assuming in all generality that `m` takes `[T_1 <: U_1 >: L_1, ..., T_n <: U_n >: L_n]` as type parameters and `(A_1, ..., A_k)` as the first clause of (explicit or implicit) term parameters, then `m` is expanded as follows:
-
-1. Copies of `T_i`s are created, and replaced in `U_i`s, `L_i`s, `A_i`s and `R`, noted respectively `T'_i`, `U'_i`, `L'_i` and `A'_i`.
-
-2. `m` is replaced by the following: 
-~~~ scala
-[T'_1 <: U'_1 >: L'_1, ... , T'_n <: U'_n >: L'_n] 
-  => (a_1: A'_1 ..., a_k: A'_k) 
-  => m[T'_1, ..., T'_n](a_1, ..., a_k)
-~~~
-
-3. `m[T'_1, ..., T'_n](a_1, ..., a_k)` is type-checked (with no expected type).
-
-Note: Again, type checking takes care of term inference, and there is no overloading resolution necessary, as there is only one option by assumption.
-
-#### Default
+#### Non-polymorphic expected type
 
 No polymorphic eta-expansion is performed, this corresponds to the old behaviour, written here as a reminder:
 
@@ -394,7 +350,7 @@ As this proposal never generates code that couldn't have been written by hand be
 
 #### Source
 
-This proposal conserves source compatibility when a non-polymorphic type is present, since by definition the behaviour is the same.
+This proposal conserves source compatibility when a non-polymorphic expected type is present, or when there is no expected type, since by definition the behaviour is the same.
 
 In the case the expected type is polymorphic, either the code did not compile before, or there was an implicit conversion from the inferred monomorphic function to the expected polymorphic function. In the latter case, source compatibility is broken, since polymorphic eta-expansion will apply before search for implicit conversions, for example:
 
@@ -410,24 +366,11 @@ val function: [T] => T => T = method
 // now: method is eta-expanded to [T] => T => T (conv is not called)
 ```
 
-When there is no expected type, this proposal breaks source compatibility, in this regard it is essentially a change in type inference, and therefore has all the usual repercussions of changing type inference, for example:
-
-```scala
-def method[T](x: T): T = x
-val function = method // was Any => Any is now [T] => T => T
-val y = function(5) // was Any is now Int
-
-def lookFor[T](x: T)(using u: T): T = u
-lookFor(method) // was searching for Any => Any, is now searching for [T] => T => T
-// This change in search can find different instances, and thus potentially wildly different behaviour !
-```
-
-While these examples might seem damming, this is no different than any other change to type inference.
-
 ### Restrictions
 
 Not included in this proposal are:
 
+* Applying polymorphic eta-expansion when there is no  return type
 * Expanding `[T] => T => T` to `[T] => T => Id[T]` to make `tuple.map(identity)` work (might work out of the box anyways, but not guaranteed)
 * Expanding `x => x` to `[T] => (x: T) => x` if necessary (and generalizations)
 * Expanding `_` to `[T] => (x: T) => x` if necessary (and generalizations)
@@ -447,22 +390,6 @@ If you think of anything else that is worth discussing about the proposal, this
 
 <!-- If some design aspects are not settled yet, this section can present the open questions, with possible alternatives. By the time the proposal is accepted, all the open questions will have to be resolved. -->
 
-#### Overloaded methods and no expected type
-
-In the case where there is no expected type, there is nothing to guide overloading resolution, and it becomes complicated to find a good metric for the "best" variant, for example where we compare signatures in pairs:
-
-~~~ scala
-(A)(B): R
-(A)(using C): R // currently more specific
-
-(A)(B): R    // currently more specific
-(A)[T](T): R
-
-(A)(B): R          // currently more specific
-(A)[T](using T): R // intuitively more specific ?
-~~~
-
-As we have not yet been able to find a good universal and intuitive heuristic, we propose to let this question be settled on during the implementation phase, as the ease of implementation can help to choose between equivalently good imperfect metrics.
 <!--
 ## Alternatives
 -->