Imported From: https://issues.scala-lang.org/browse/SI-8387?orig=1
Reporter: @xeno-by
Affected Versions: 2.11.0-RC1

@densh said:
Related

scala> val q"$expr[..$targs](...$argss)" = q"new C(1, 2)"
expr: reflect.runtime.universe.Tree = new C
targs: List[reflect.runtime.universe.Tree] = List()
argss: List[List[reflect.runtime.universe.Tree]] = List(List(1, 2))

@densh said:
Considering the fact that RC2 doors are closed and we might not have RC3 at all, I'd suggest documenting current behavior with recommendation to use more specific patterns with triple-dot applications.

@xeno-by said:
@adriaanm What are our plans wrt RC3?

@adriaanm said:
We're not aware of any reason to have one, and I hope it stays that way :-)

@xeno-by said (edited on Mar 15, 2014 3:36:40 PM UTC):
No way!!! Are we going to release at last??!! /party

@adriaanm said:
Well, I've dusted off my party hat, but let's get through another(!) week without blockers before we put it on :-)
In other words, once RC2 is out, we'll wait for reports of blocker bugs until March 24 -- if not, RC2 == final

@densh said (edited on Mar 25, 2014 12:52:21 PM UTC):
After I've player with limiting q"$f(...$argss)" applicability I've come to think that imposing some rules on its matching behavior will make it harder to reason about. Now you have a very simple explanation: if there are any applications they will be in argss, if there are none argss == Nil. If you impose restriction to not match some trees with Nil value this rules stops being simple and needs additional exceptional explanations.

I do agree that matching of new as an application is confusing though, as new is not an application from syntactical point of view but an instantiation of an object with given template.

@densh said:
scala/scala#3656