Skip to content

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

Closed
LPTK opened this issue May 2, 2019 · 6 comments
Closed

Do not deprecate @compileTimeOnly #6419

LPTK opened this issue May 2, 2019 · 6 comments

Comments

@LPTK
Copy link
Contributor

LPTK commented May 2, 2019

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 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
                   ^
@nicolasstucki
Copy link
Contributor

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

@LPTK
Copy link
Contributor Author

LPTK commented May 2, 2019

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

@liufengyun
Copy link
Contributor

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.

@nicolasstucki
Copy link
Contributor

As @liufengyun said, #6416 did not deprecate @compileTimeOnly. Though we still do not have support for it.

nicolasstucki added a commit to dotty-staging/dotty that referenced this issue May 2, 2019
@LPTK
Copy link
Contributor Author

LPTK commented May 2, 2019

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.

nicolasstucki added a commit to dotty-staging/dotty that referenced this issue May 2, 2019
nicolasstucki added a commit to dotty-staging/dotty that referenced this issue May 2, 2019
nicolasstucki added a commit to dotty-staging/dotty that referenced this issue May 2, 2019
nicolasstucki added a commit to dotty-staging/dotty that referenced this issue May 3, 2019
nicolasstucki added a commit to dotty-staging/dotty that referenced this issue May 3, 2019
@nicolasstucki
Copy link
Contributor

Actually what we cannot implement using scala.compiletime.error(...) is

@compileTimeOnly(...)
object Unit { ... }

Therefore both abstractions are useful in different contexts.

nicolasstucki added a commit to dotty-staging/dotty that referenced this issue May 3, 2019
nicolasstucki added a commit to dotty-staging/dotty that referenced this issue May 3, 2019
nicolasstucki added a commit to dotty-staging/dotty that referenced this issue May 3, 2019
nicolasstucki added a commit that referenced this issue May 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants