Issue "positional after named argument" errors

[odersky]

Issue "positional after named argument" errors if a positional argument follows a named argument and one of the following is true:

• There is a formal argument before the argument position that has not yet been instantiated with a previous actual argument, (either named or positional), or
• The formal parameter at the argument position is also mentioned in a subsequent named parameter.

This brings the behavior largely in line with Scala 2.

Fixes #18122

[som-snytt]

bar2(x = 1, ys = 2, ys = 3)? probably parameter ys is already instantiated.

bar2(x = 1, 2, ys = 3) // error: positional after named on L45 is slightly confusing message.

I expect that if named args do not change ordering, then it's always OK.

I see the rule that's being enforced is that ys always names the start of the repeated param. Then the positional arg 2 is unknown detritus.

[odersky]

All true, but positional after named is technically correct, and it would be messy to change the logic to emit a different error message. Keeping logic clean in the compiler is an underestimated good. Lose it and you enter quickly a downward slide where in the end nobody understands the code anymore.

[prolativ]

@som-snytt any further objections or can we get this merged?

[som-snytt]

LGTM! I especially appreciate

Keeping logic clean in the compiler is an underestimated good.

It's easy to go overboard, and the voice of experience is also an underestimated good.

I haven't looked at Scala 2 messaging yet, which I will do in light of:

I see the rule that's being enforced is that ys always names the start of the repeated param.

[WojciechMazur]

There are 3 OpenCB projects which are now failing after this change, but I would not say it's an regression, but rather an improvement.

Project	Version	Build URL	Notes
carlos-verdes/zio-arangodb	0.3.1	Open CB logs
fabiopinheiro/scala-did	0.1.0-M9 -> 0.1.0-M10	Open CB logs
greenfossil/data-mapping	1.0.5 -> 1.0.7	Open CB logs

My question is, @Kordyjan should we backport this change to Scala 3.3.x?
One example of weakly-defined behaviours possibly leading to bugs before this change was:

case class Foo(a: Int, b: Long, c: Int){
  def x = copy(b = 0L, 0) // is the second param targetting `a` or `c`?
}

[som-snytt]

The previous (interesting) expectation was that a named arg "resets" the position, such that defaults to the left of that position are supplied. (Such as on zio-arangodb.)

Welcome to Scala 2.13.11 (OpenJDK 64-Bit Server VM, Java 20.0.1).
Type in expressions for evaluation. Or try :help.

scala> def f(x: Int, y: Int = 42, z: Int, a: Int) = List(x,y,z,a).sum
def f(x: Int, y: Int, z: Int, a: Int): Int

scala> f(1, z=3, 4)
                 ^
       error: positional after named argument.
        ^
       error: not enough arguments for method f: (x: Int, y: Int, z: Int, a: Int): Int.
       Unspecified value parameter a.

which on 3.3.0

Welcome to Scala 3.3.0 (20.0.1, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.

scala> def f(x: Int, y: Int = 42, z: Int, a: Int) = List(x,y,z,a).sum
def f(x: Int, y: Int, z: Int, a: Int): Int

scala> f(1, z=3, 4)
val res0: Int = 50

my dotty just finished compiling, so for completeness

scala> f(1, z=3, 4)
-- Error: --------------------------------------------------------------------------------------------------------------
1 |f(1, z=3, 4)
  |          ^
  |          positional after named argument
1 error found

The wrong expectation is not terrible, because visually you align the named arg with the signature. It feels like a feature, because otherwise default args are convenient only in trailing position.

The case class copy example is deceptive because there is no signature to look at besides the class parameters. (You don't see the defaults, in other words.)

The argument for backporting is that it's never too early to correct a mistaken expectation.