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

SyntacticApply is too permissive #8387

Closed
scabug opened this issue Mar 9, 2014 · 9 comments
Closed

SyntacticApply is too permissive #8387

scabug opened this issue Mar 9, 2014 · 9 comments
Assignees
Labels
Milestone

Comments

@scabug
Copy link

@scabug scabug commented Mar 9, 2014

At the moment q"$core..$targs" is going to match any tree. If the tree is not an application, then targs will be Nil, argss with be Nil, and core will be the entire tree.

This behavior is caused by the desire to have val q"$core(...$argss)" = q"foo.bar" working, which is I think a good thing, given the semantics of application in Scala. However, it also makes quasiquotes very permissive, which would probably lead to confusion.

I also assigned Critical priority to this issue, because if we release Scala 2.11.0 with this not fixed, then everyone's going to depend on this behavior, and we might break a lot of code when fixing this issue.

@scabug
Copy link
Author

@scabug scabug commented Mar 9, 2014

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

Loading

@scabug
Copy link
Author

@scabug scabug commented Mar 14, 2014

@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))

Loading

@scabug
Copy link
Author

@scabug scabug commented Mar 15, 2014

@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.

Loading

@scabug
Copy link
Author

@scabug scabug commented Mar 15, 2014

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

Loading

@scabug
Copy link
Author

@scabug scabug commented Mar 15, 2014

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

Loading

@scabug
Copy link
Author

@scabug scabug commented Mar 15, 2014

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

Loading

@scabug
Copy link
Author

@scabug scabug commented Mar 15, 2014

@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

Loading

@scabug
Copy link
Author

@scabug scabug commented Mar 25, 2014

@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.

Loading

@scabug
Copy link
Author

@scabug scabug commented Mar 25, 2014

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants