default arguments of inline functions are not constant (leading to error message leaking implementation details)

[rmgk]

Compiler version

3.1.2

Minimized example

inline def fun(a: String = "default"): Int =
  inline if a == "default" then 2 else 3

@main def run(): Unit = println(fun())

Output

Macro.scala:6:33: Cannot reduce `inline if` because its condition is not a constant value: a$proxy1.==("default") [6:33]

Expectation

At the very least, the error is confusing because it leaks the implementation details of default arguments.

The whole thing works as expected if a is marked as inline, thus maybe having the proxy “constant” should be the default for inline methods?

(As motivation, this pattern is somewhat useful to use a different implementation when default arguments are not changed)

[szymon-rd]

Thanks for reporting!

[rmgk]

As kind of an extended example, if we print the following code (using an outer macro that calls Expr.show):

inline def f(x: => Any)(inline a: String = "default"): Int = a.length
f(List.empty)()

we get

{
  inline def f(x: => scala.Any)(a: scala.Predef.String): scala.Int = (a.length(): scala.Int)
  inline def f$default$2(`x₂`: => scala.Any): scala.Predef.String @scala.annotation.internal.InlineParam @scala.annotation.unchecked.uncheckedVariance = ("default": scala.Predef.String @scala.annotation.internal.InlineParam @scala.annotation.unchecked.uncheckedVariance)
  def x$1: scala.collection.immutable.List[scala.Any] = scala.List.empty[scala.Any]
  def x$proxy2: scala.collection.immutable.List[scala.Any] = x$1

  ({
    def x$proxy1: scala.collection.immutable.List[scala.Any] = x$1

    ("default": scala.Predef.String @scala.annotation.internal.InlineParam @scala.annotation.unchecked.uncheckedVariance)
  }.length(): scala.Int)
}

This is a strange and weird interaction of features, but results in heaps of dead code (only "default".length() in the above is executed). With inline parameters it is especially unfortunate because all of this usually hidden default parameter encoding becomes visible in the program.

[odersky]

I think the best solution to this would indeed be to drop default getters altogether and treat default values as inlineable. That is a rather big chunk of implementation and migration effort, however.

One migration problem is that this would not support virtual dispatch for default getters. So to make progress on this, a first step would have to be to deprecate overriding of default values. That is, the following is currently legal, but should be deprecated:

class A:
  def f(x: Int = 1)
class B extends A:
  override def f(x: Int = 2)

Going there has certainly the potential make the language more powerful and intuitive to use.

In particular, we can expect the following benefits:

• Code generation is simplified
• Overaloading and default arguments can be freely mixed
• Default arguments can use preceding parameters in same section
• Issues that are currently intractable would have an easy fix

But since we have to deprecate and remove overriding of default values first, it would be a multi-year effort to get there. We'd need a group of people with the stamina to see this through.

[rmgk]

In general, I agree with the larger view, and I do not rely on this capability here, so its fine by me if we keep the status quo (until a team with enough stamina addresses this 😃).

However, there is one specific issue smaller in scope:
For: (1) an inline parameter, (2) with a default argument, (3) in a second parameter list.
The generated proxy is an inline def but its arguments are by name parameters. And I think they should be inline parameters as well.

To explain with an example, as seen from my second snippet, currently the following definition:

inline def f(x: => Any)(inline a: String = "default"): Int = a.length

generates a proxy of the shape:

  inline def f$default$2(`x₂`: => scala.Any): scala.Predef.String  = ("default")

this does not depend on x₂, so after inlining we get these little blocks: for the inlined default argument

  ({
    def x$proxy1: scala.collection.immutable.List[scala.Any] = x$1

    ("default")
  })

which are … not constant because of the definition in the beginning even though that definition is unused.

I think that might also improve the the following issue, consider that we have

inline def myfun(inline a: String)(inline b: Int = 2, inline c: Int = 3): Int = b + c

and we do

myfun({println("ha"); "b"})()

this will print ha twice, because both the b and the c implicitly depend on a and the inlined .
Note that the same issue occurs if b and c are by name parameters.

The reason seems to be that somewhere in the proxying a is assigned to a val in the proxies of both b and c. Using inline parameters for the proxy methods might just inline the code into nothingness (as it should be).