-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Do not deprecate @compileTimeOnly #6419
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
Comments
scala> trait A { inline def f: Int = scala.compiletime.error("oops") }
// defined trait A
scala> class B extends A { override def f = 0 }
// defined class B
scala> (new B).f
val res0: Int = 0
scala> (new B : A).f
1 |(new B : A).f
|^^^^^^^^^^^^^
|oops |
Okay, it's nice to know one can override inline methods. Could you please address the other point I raised?
|
We want to discourage users of Dotty from using We think that a compiler warning is the best approach to achieve the gaol, while Scala2 code continues to compile -- we assume a warning will not cause much migration pain. |
As @liufengyun said, #6416 did not deprecate |
Thanks for the answers. I was mostly concerned with death by a thousand papercuts for people trying to migrate or cross compile. If the Scala 3 transition is to be successful, I think it's a good idea to strive and reduce the number of annoyances and the amount of cognitive load associated with migration/cross-compilation. In that context, this warning seems like it could do more harm than good. Feel free to close the issue, but I'd appreciate if this kind of decisions were adequately balanced with the negative consequences they may cause to users, however small and significant these consequences might seem – in aggregate, they can eventually add up to something significant. |
Actually what we cannot implement using @compileTimeOnly(...)
object Unit { ... } Therefore both abstractions are useful in different contexts. |
Fix #6419: Support @compileTimeOnly
What's the rationale for deprecating
@compileTimeOnly
in #6416?First, doing that would introduce unnecessary migration pain, for little gain (I assume it's quite straightforward to support in the compiler). Second, the proposed alternative doesn't cover all use cases of
@compileTimeOnly
well. For example, can you encode the following with justinline
anderror
?The text was updated successfully, but these errors were encountered: