Allow by-name repeated parameters

[odersky]

Motivation

Scala so far does not allow by-name repeated parameters. But I can't see a good reason why this combination should be disallowed. Also, the combination is necessary to allow vararg parameters that are passed as expressions to inline methods (instead of being lifted out).

Syntax

The syntax for ParamType becomes

  ParamType         ::=  [`=>'] ParamValueType
  ParamValueType    ::=  Type [`*']              

The syntax implies that a type such as => T*, which is both by-name and repeated is interpreted as => (T*), that is, as a by-name type of a repeated type.

Translation Rules

If a parameter has a by-name repeated type => T* it matches an arbitrary number of actual arguments of type T. As usual for by-name parameters, the arguments are not evaluated at the point of call. Instead, all arguments are evaluated each time the parameter is referenced in the called method.

The same holds for an vararg argument of the form e: _*. The argument expression e is evaluated each time the parameter is referenced in the called method.

[DarkDimius]

Instead, all arguments are evaluated each time the parameter is referenced in the called method.

So => T* means Function0[Seq[T]].
Is there an intention to allow (=> T)* which would mean Seq[Function0[T]]?

[odersky]

@DarkDimius No intention to provide both.

[nafg]

@DarkDimius what's the benefit of the latter?

[DarkDimius]

In some cases, you could be interested in knowing number of arguments without forcing the actual arguments.
Lets say you want to implement a function, that prints progress of evaluating its arguments.
Ie given a call

exec(expr1, expr2, expr3, expr4)

you want to see output

[timestamp] 4 commands scheduled for execution
[timestamp] Running command 1 out of 4
[timestamp] Running command 2 out of 4
[timestamp] Running command 3 out of 4
[timestamp] Running command 4 out of 4
[timestamp] Done

I do not have a strong opinion on (=> T)*, as it does not play well with e: _*. Presence of both forms could also be a source of confusion.

[odersky]

I think it would be oonfusing. Also, we'd have to the somehow say that mentioning a by-name
parameter in a function does sometimes not force the expression to be evaluated. Looks messy.

[nafg]

@DarkDimius could you just do something like:

implicit class ByNameWrapper[A](a: =>A) { def theA = a }

def exec[A](as: ByNameWrapper[A]*)

[nafg]

Seems to work (in 2.11.6): http://scastie.org/9184

[DarkDimius]

@nafg indeed. No reason to treat it specially than.

[retronym]

Would these avoid evaluating the arguments?

def foo(a: => Any*) = ()
def bar(a: => Any*) = foo(a : _*)
def baz(a: => Seq[Any]) = foo(a : _*)
bar(???, ???)
baz(Seq(???, ???))

[odersky]

None of them should evaluate the arguments.

[nafg]

It's more general sure, but as Runar says, liberties constrain and constraints liberate. Or as the Talmud says, whoever increases, decreases. Specifically, as Martin has said, by taking the more general interpretation the implementation is forced to be much less performant. Also (he said) it would a much more complicated implementation. How would you implement such a thing? In fact how would it even work? Given def m(xs: =>Int*) { // what is the type of xs? val ys = xs.to[X] // where X is List, Seq, whatever. What is the element type? val z = xs.head // what does this desugar to? xs.filter(somePredicate).foreach(println) // what are the semantics? } I guess you could either (1) make xs have some special collection type, e.g. LazyList, or (2) make it be some sort of Seq[=>Int], with new rules. On second thought, if we had an actual LazyList as has been discussed (unlike Stream where the head is not truly lazy), one could suggest that `T*` becomes a Seq while `=>T*` becomes a LazyList. But actually, by-name is different than lazy: lazy means evaluated 0 or 1 times, but by-name means evaluated 0 or more times. So you'd need a new collection (ByNameSeq) which is like LazyList but much less useful. On a different note (OT), it would be interesting to be able to declare parameters to be like lazy rather than regular call-by-name.

…

On Fri, Aug 19, 2016 at 12:28 PM Sean Vieira ***@***.***> wrote: I would argue that treating => T* as a Seq[Function0[T]] makes far more sense that Function0[Seq[T]] because it is possible to do everything the latter enables in terms of the former, but not vice-versa. An example: def firstSuccessful(actions: => Boolean*) = actions.toStream.map(action => action()).isDefined — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#499 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGAUMfX67MF6WCEK06IOYqAonsWjZdTks5qhdmigaJpZM4EH-0W> .

[SethTisue]

Naftoli's implicit class workaround works in Scala 2, but it does not work in Scala 3: https://scastie.scala-lang.org/yJ14pr86TMOxM59smJSGLg