Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification: By-name varargs unsupported #5787

Closed
scabug opened this issue May 10, 2012 · 14 comments
Closed

Clarification: By-name varargs unsupported #5787

scabug opened this issue May 10, 2012 · 14 comments
Labels
enhancement fixed in Scala 3 This issue does not exist in the Scala 3 compiler (https://github.com/lampepfl/dotty/) language spec

Comments

@scabug
Copy link

scabug commented May 10, 2012

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
Copy link
Author

scabug commented May 10, 2012

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

@scabug
Copy link
Author

scabug commented May 10, 2012

@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
Copy link
Author

scabug commented May 15, 2012

@lrytz said:
spec clarification needed

@scabug
Copy link
Author

scabug commented May 15, 2012

@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
Copy link
Author

scabug commented May 15, 2012

@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
Copy link
Author

scabug commented Jul 30, 2012

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

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

So it's clear they cannot be combined.

@scabug
Copy link
Author

scabug commented Feb 26, 2014

@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
Copy link
Author

scabug commented Feb 26, 2014

@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
Copy link
Author

scabug commented Jul 24, 2014

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

@scabug
Copy link
Author

scabug commented Jun 6, 2015

@som-snytt said:
scala/scala3#499

@scabug
Copy link
Author

scabug commented Jun 19, 2015

@scabug scabug added this to the Backlog milestone Apr 7, 2017
@adriaanm adriaanm removed their assignment Sep 28, 2018
@smarter smarter added the fixed in Scala 3 This issue does not exist in the Scala 3 compiler (https://github.com/lampepfl/dotty/) label Oct 19, 2018
@scala scala deleted a comment from scabug Apr 13, 2020
@SethTisue
Copy link
Member

closing as now out of scope for Scala 2

@som-snytt
Copy link

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

I just got that.

@SethTisue SethTisue removed this from the Backlog milestone Apr 14, 2020
@martijnhoekstra
Copy link

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

@SethTisue SethTisue closed this as not planned Won't fix, can't repro, duplicate, stale Feb 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement fixed in Scala 3 This issue does not exist in the Scala 3 compiler (https://github.com/lampepfl/dotty/) language spec
Projects
None yet
Development

No branches or pull requests

6 participants