Clarification: By-name varargs unsupported

[scabug]

This is edge-use-case, but:

scala> def m(a:Int,bs: =>Int*) = 7
<console>:1: error: ')' expected but identifier found.
       def m(a:Int,bs: =>Int*) = 7
                            ^

scala> def n(is: (=>Int)*) = 7
<console>:1: error: no by-name parameter type allowed here
       def n(is: (=>Int)*) = 7
                  ^

scala> def q(is: =>(Int *)) = 5  // not my intention
<console>:1: error: no * parameter type allowed here
       def q(is: =>(Int *)) = 5

Am I the only one who experiences a cognitive hiccup every time I have to disambiguate "named parameter" and "by-name parameter?" Internally (to myself), I've started calling (denoting) params that have call-by-name semantics "eval params" because of the loose notion that they are evaluated on reference. ("Deferred params" conveys the idea that evaluation is deferred, but people get confused about deferred to when, especially under partial application, and deferred doesn't suggest multiple evaluation. I hope Paul reads this and has a better word for it -- besides "evil params", of course.)

I haven't thought closely about this, except my terminology hangup, but the Seq[=>T] view might be a reason to ignore the use case.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-5787?orig=1
Reporter: @som-snytt
Affected Versions: 2.10.0
Duplicates #237

[scabug]

@paulp said:
Yes, the terminology we have to describe evaluation semantics is unreasonably impoverished. I have no better word, but if ambiguity is a concern I call by-name parameters thunks (whether that's an accurate use of that word or not, people at least tend to know what I mean.)

I have asked martin for by-name + varargs before, the use case I often encounter being logging - I'd really like to be able to write

def log(fmt: String, args: =>Any*) = if (logging) println(fmt.format(args: _*))

log("%s: %s %s", foo, bar, baz)

A single instance could serve to hold all three (or N) methods, something like

class AnonVarargs extends (Int => T) {
  def apply(index: Int) = index match {
    case 0 => foo
    case 1 => bar
    case 2 => baz
  }
}

There was some objection which I no longer remember.

[scabug]

@lrytz said:
spec clarification needed

[scabug]

@adriaanm said:
more notes from the meeting: would be useful to have, but let's clarify it's disallowed for now. Can always implement once we've come up for air after 2.10.0

[scabug]

@som-snytt said:
This might fall under the same rubric: var varargs. Given (var is: Int*), you can assign one Int, is=1, but not is=List(1,2,3). Also, someone wanted an implicit convert(Seq) to apply to a vararg, which is expected if vararg is type Seq inside the method. With respect to overloading (how to explain how it works), it was suggested the spec should talk about A* with the same reverence applied to =>A. (That is, a useful fiction.)

[scabug]

@odersky said:
Note that the spec is unambiguous wrt this.

ParamType         ::=  Type 
                  |  `=>' Type 
                  |  Type `*'

So it's clear they cannot be combined.

[scabug]

@adriaanm said:
Apologies to those holding their breath. I will start working on spec cleanup as soon as RC1 is out the door. Promise.

[scabug]

@som-snytt said:
Whew. It was my mistake to misread the spec when I was learning the language (specese, as it's been called). I thought this would make an interesting (at the time) contribution, but paulp's use case is obviated by other features (macros). By coincidence, I was just touching this production in my last PR, wondering if Int*`` is a good param type, with star as a regular identifier instead of some intermediate category.

[scabug]

@som-snytt said:
Maybe Adriaan would like an issue with fewer digits.

[scabug]

@som-snytt said:
scala/scala3#499

[scabug]

@SethTisue said:
this is now SIP-24, http://docs.scala-lang.org/sips/pending/repeated-byname.html

[SethTisue]

closing as now out of scope for Scala 2

[som-snytt]

-- Apologies to those holding their breath.
-- Whew.

I just got that.

[martijnhoekstra]

To be fair, the guy who said that is known for sneaking in witticisms and puns that can go undetected for quite a while.