What's the rationale for deprecating @compileTimeOnly in https://github.com/lampepfl/dotty/pull/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 just inline and error?
scala> trait A { @scala.annotation.compileTimeOnly("oops") def f: Int }
defined trait A
scala> class B extends A { def f = 0 }
defined class B
scala> (new B).f
res0: Int = 0
scala> (new B : A).f
<console>:14: error: oops
(new B : A).f
^
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?
What's the rationale for deprecating
@compileTimeOnly
doing that would introduce unnecessary migration pain, for little gain
We want to discourage users of Dotty from using @compileTimeOnly, and make them aware that there is a better alternative.
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 @compileTimeOnly. Though we still do not have support for it.
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 scala.compiletime.error(...) is
@compileTimeOnly(...)
object Unit { ... }
Therefore both abstractions are useful in different contexts.
Most helpful comment
Actually what we cannot implement using
scala.compiletime.error(...)isTherefore both abstractions are useful in different contexts.