varargs and named parameters ...
Dianne Marsh
The order of named parameters passed affects behavior in an unexpected way.
class Family(val mom: String, val dad: String, val kids:String*)
// this works
val f1 = new Family(mom="Mom", dad="Dad")
// this does not
val f2 = new Family(dad="Dad", mom="Mom")
In summary, parameters passed in same order as class definition work fine. Parameters passed in a different order fail with complaint:
error: when using named arguments, the vararg parameter has to be specified exactly once
Only causes problem when also declaring a variable argument list.
-------
Simon Ochsenreither
while the error messages seem to be correct, the current behavior has led to complaints that the rules are too strict, and I certainly agree with that point.
I remember that there have been some efforts to make the compiler behaving more intelligently, but is has been shown that coming up with a solution which is
a) easy to specify, complete and unambiguous AND
b) easy to implement and test AND
c) easy to understand AND
d) easy to use
is surprisingly hard.
As far as I know, that's the reason why the spec/compiler is pretty conservative and rejects code which looks straightforward to the human eye.
I think I remember that there were some commits regarding named parameters a few months ago. Did you try your code examples with Scala 2.10? Maybe there are some improvements already available?
Bye,
Simon
Som Snytt
I posted the following as a bug and it was rejected as "expected behavior".
No one had a chance to comment with a link to an explanation, but I believe Simon.
An application that uses out-of-order params (oops) with varargs must look like:
f(b=2,a=1,cs=Nil:_*)
f(b=2,a=1,cs=Seq(3,4):_*)
or
f(cs=Seq(3,4):_*,a=1,b=2) // which looks more interesting for some reason
Each param needs a positional arg, named arg or default arg; and repeated params can't have a default.
Missing repeated params can't be taken to default to Nil:_* because of overloading, presumably.
There's an old issue about an interaction between varargs and overloading that just got some attention:
https://issues.scala-lang.org/browse/SI-2991
which indicates how persistent the cornery use cases are.
Maybe I'll wait until morning to explain this one to my dog, who is always willing to listen:
scala> object F {
| def f(i: Int, ss: String*) = i+1
| def f(i: Int, j: Int = 5) = i+j
| }
defined module F
scala> F.f(1)
res9: Int = 2
scala> F.f(i=1)
<console>:9: error: ambiguous reference to overloaded definition,
both method f in object F of type (i: Int, j: Int)Int
and method f in object F of type (i: Int, ss: String*)Int
match argument types (i: Int)
F.f(i=1)
^
(Oh yeah, in the first case, prefer the method without default args; in the second case? Wait, wait, don't tell me.)
Here is a use case:
scala> object K {
| def f(i: Int, j: Int, ss: String*) = i+1
| def f(i: Int, j: Int, k: Int = 5) = i+j+k
| }
defined module K
scala> K.f(j=1,i=2) // oops disambiguates
res18: Int = 8
scala> K.f(i=1,j=2)
<console>:9: error: ambiguous reference to overloaded definition,
both method f in object K of type (i: Int, j: Int, k: Int)Int
and method f in object K of type (i: Int, j: Int, ss: String*)Int
match argument types (i: Int,j: Int)
K.f(i=1,j=2)
^
scala> K.f(1,2)
res20: Int = 2
Paul Phillips
Here's the issue. This smacks of leaky implementation details.