Details
-
Type:
Bug
-
Status: Open
-
Priority:
Minor
-
Resolution: Unresolved
-
Affects Version/s: Scala 2.10.0
-
Fix Version/s: Backlog
-
Component/s: Specification
-
Labels:None
-
Environment:
Welcome to Scala version 2.10.0-20120501-234146-b27abca41a (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_22).
Description
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.
Attachments
Issue Links
- duplicates
-
SI-237 Parameters should be allowed as by-name and repeated
-
- Open
-