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
Provide way to annotate method as compile-time-only #6539
Comments
Imported From: https://issues.scala-lang.org/browse/SI-6539?orig=1 |
@paulp said: |
@xeno-by said: |
@gkossakowski said: |
@retronym said: scala> @deprecated("must be enclosed in M.m") def foo = 0
warning: there were 1 deprecation warnings; re-run with -deprecation for details
foo: Int
scala> import language.experimental.macros
import language.experimental.macros
scala> def mImpl(c: Context)(a: c.Expr[Any]) = c.universe.reify(())
mImpl: (c: scala.reflect.macros.Context)(a: c.Expr[Any])c.universe.Expr[Unit]
scala> def m(a: Any) = macro mImpl
m: (a: Any)Unit
scala> foo
<console>:38: warning: method foo is deprecated: must be enclosed in M.m
foo
^
res5: Int = 0
scala> m(foo) |
@xeno-by said: |
@retronym said: |
@harrah said: |
@xeno-by said: |
@gkossakowski said: |
@retronym said (edited on Nov 6, 2012 5:21:39 PM UTC): |
@gkossakowski said: Once annotation mechanism described in this ticket is used in the wild we can sit down and write SIP for it and consider the design for inclusion in Scala some release. WDYT? |
@retronym said:
Given that we can put the annotation under an experimental package, I don't buy the argument about allowing the feature to evolve before inclusion. Doubly so given that the impact on compiler complexity is so small. |
@adriaanm said: |
@retronym said: -class deprecated(message: String = "", since: String = "") extends scala.annotation.StaticAnnotation
+class deprecated(message: String = "", since: String = "", fatal: Boolean = false) extends scala.annotation.StaticAnnotation |
@xeno-by said (edited on Nov 6, 2012 8:10:17 PM UTC): |
@retronym said: Perhaps it could be a particular brand of macro annotation that executes in the context of the call-site, and is able to choose to do it's work post typer. But I think we're trying too hard to find some beauty/generality here. |
@gkossakowski said: |
@retronym said: |
@paulp said: class fatallyDeprecated(...) extends deprecated |
@xeno-by said: I'm not closing the bug yet, since the annotation is deemed to be a temporary measure until we have macro tools that will let us solve this problem without any changes to the compiler. |
@xeno-by said: |
@retronym said: |
@xeno-by said: |
@xeno-by said: |
@xeno-by said: |
One pattern used with macros is to have an unimplemented stub method that is valid only in the context of a macro and is then removed by that macro:
The problem is that use of
value
outside of the macro is not caught at compile time, but at runtime. For example, the following throws an exception at runtime because value is not used within the task macro that would otherwise remove the call to it.The proposed solution is to have an annotation or some other way of telling the compiler that calls to
value
that survive typechecking are an error. For example,This would be useful for standard macro-related methods like splice as well.
The text was updated successfully, but these errors were encountered: