Add a lint/warning for the Interaction between using and default parameters

[bracevac]

Compiler version

3.7.x

Minimized code

//> using scala 3.7.0

def fun(x: Int)(using p: Int, q: Int = 0): Int = 
  if x <= 0 then p * q
  else fun(x - 1)(using p = p + x)

@main def test = 
  println(fun(3)(using p = 0, q = 1))

Output

We would expect that the computation outputs (3 + 2 + 1) * 1 = 6, but
it's actually (3 + 2 + 1) * 0 = 0, because in the recursive call to fun, the default value p = 0 takes precedence over the enclosing p (which we set to 1 initially).

Expectation

That's extremely sneaky and feels wrong. I've seen instances of this interaction of defaults and implicits in the Scaladoc codebase (where implicit parameters keep getting added by people in AST traversals, in itself a problem for another time).

At least we should get a big fat warning that something surprising is going on,
but ideally, we change the behavior so that the default only applies if implicit resolution cannot find a binding in context.

[som-snytt]

scala-cli compile --server=false -S 2 -Xlint:help
Enable recommended warnings
***
  recurse-with-default    Recursive call used default argument.

e.g.

.../recur-default.scala:3: warning: Recursive call used default arguments instead of passing current argument values.
  def recur(i: Int, j: Int = 0): Int = recur(i)
                                            ^
1 warning

Edit: I see in scala/scala#8598

• it was retronym's idea
• it was a lot of linting

Edit: that PR was mostly other lints but I recall the pernicious recursion at jsig https://github.com/scala/scala/blob/2.13.x/src/compiler/scala/tools/nsc/transform/Erasure.scala#L279

[bracevac]

After discussing in the core meeting: There should be a warning/lint (tbd) for these situations, which are fundamentally ambiguous. We'll try to have it for 3.8.

[prolativ]

An alternative example without recursion and without possibly conflicting given instances for the same type:

def fun(using s: String, i: Int = 1): String = s * i
def funCurried(using s: String)(using i: Int = 1): String = s * i

@main def test =
  locally {
    given String = "ab"
    println(fun) // prints "ab"
    println(funCurried) // prints "ab"
  }
  locally {
    given String = "ab"
    given Int = 2
    println(fun) // prints "abab"
    println(funCurried) // prints "abab"
  }
  locally {
    println(fun(using s = "ab")) // prints "ab"
    println(funCurried(using s = "ab")) // prints "ab"
  }
  locally {
    given Int = 2
    println(fun(using s = "ab")) // prints "ab"
    println(funCurried(using s = "ab")) // prints "abab"
  }

This is indeed quite tricky.
I was just supposed to write that in some way it does actually make some sense if you think of this like this:

If you pass an explicit arguments list to a method via `(using ...)` then the compiler ignores given instances in scope and default parameter values are used instead.

But then I realized that this is not true if there is no default argument as then given instances are are taken into account again 🤯

  locally {
    given String = "ab"
    println(fun(using i = 2)) // prints "abab"
    // println(funCurried(using i = 2)) // doesn't compile
  }

[som-snytt]

My previous comment about using + defaults (which I have reread a few times since January) is
#22458 (comment)

I think "explicit using" is a useful concept. "The user wrote explicit using to supply args explicitly, and it works like any application where defaults are supplied." Because it is an implicit param list, missing args can be supplied implicitly (subsequently).

Another way to say it (I hope I don't botch it):

• constructing an explicit application, missing params are supplied by defaults. Additional args may be supplied implicitly.
• constructing an implicit application, missing params are supplied by defaults.

The extra part in the first case is for explicit using, an explicit application but for an implicit param list.

Also, please sign me up for the Coursera on this topic.

[bracevac]

I find this behavior quite unnatural for tree traversals where contextual information should be passed along (like in these outlandish things called compilers, or documentation tools).

There, the more natural perspective is that the given parameter list is the current context information, and in the recursive call I modify one specific bit of the current context with f(using foo = bar) while keeping the rest as-is.

We're not having issues in the compiler because all context is abstracted in the Context type which is a single implicit parameter. If we need to add more stuff to the context without touching most of the traversal code, we can just add more fields to the Context type. The same thing can't be said for the scaladoc code base, where people (like yours truly) keep adding extra implicit parameters to the traversals.

Bundling everything in a single context type/parameter comes at the expense of needing to access individual bits of the context using field accessors and possibly summoning the implicit context value first. A flat list of multiple named implicit arguments can be more readable.

If we don't want to/can't change how it works, perhaps we could have some concise way to say "keep the rest of the current implicit context"

def foo(x: Int)(using a: A, b: B, c: C = C(0)): D =
  ...
  foo(42)(using *.(a = A("xyz"))
  // which should be the same as
  foo(42)(using a = A("xyz"), b = b, c = c)

because a parameter list like (using a: A, b: B, c: C) can be regarded as a named tuple.

That way, we avoid the ceremony associated with a singular big context type, and remain extensible with new context parameters without having to touch existing cases in the function body.