Deprecate early initializer

[adriaanm]

No description provided.

[som-snytt]

Even the label colors are better on scala-dev.

[eed3si9n]

Is there a reason we are deprecating this before 2.14 when trait parameter is going to come? All warnings should be actionable such that the user can get rid of the warning somehow. In this case I'd get a warning saying "hey, this feature is going away." But then what am I supposed to do?

[som-snytt]

Yes, I agree, and Adriaan said on your PR, Even though, we must.

I think you're supposed to rearchitect your compiler so that you don't have early-initialized global all over the place.

How about, "early definitions are deprecated; Lightbend offers consulting services to help you rewrite your App; ask for Seth; also, App is going away too, so stop using that while you're at it."

Maybe emit the whole message only under -help or -verbose or -explain.

[adriaanm]

We could pull the old trick of only deprecating under -Xsource:2.14

…

On Thu, Jul 5, 2018 at 07:06 som-snytt ***@***.***> wrote: Yes, I agree, and Adriaan said on your PR, Even though, we must. I think you're supposed to rearchitect your compiler so that you don't have early-initialized global all over the place. How about, "early definitions are deprecated; Lightbend offers consulting services to help you rewrite your App; ask for Seth; also, App is going away too, so stop using that while you're at it." Maybe emit the whole message only under -help or -verbose or -explain. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#513 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFjy4NmzZ2uwgKiBrvhZr_oaVaRYR8Gks5uDZ7lgaJpZM4T_Sjg> .

[eed3si9n]

If you have the cycle for it during 2.13.x, it would be cool to implement trait parameters too under -Xsource:2.14, which acts as a carrot. If you had that, you can remove early initializer under the flag as well. That might gives an opportunity to beta test the feature, and also encourage people to rip out other removals that we got into -Xsource:2.14.

[smarter]

Is there a reason we are deprecating this before 2.14 when trait parameter is going to come?

So far, it looks like Dotty (and by extension Tasty) will not support early initializers. If we want Tasty to be the one true backend of Scala 2.14, this means that early initializers need to be removed in 2.14 and so should be deprecated in 2.13. Alternatively we could tweak Tasty and Dotty to work with early initializers, but that will require some amount of work (and will need to be supported for a long time since Tasty should never break compatibility).

In this case I'd get a warning saying "hey, this feature is going away." But then what am I supposed to do?

Depending on what you used early initializers for, you may be able to rewrite your code without needing trait parameters, e.g in:

trait A {
  val x: Int
  println("A.x: " + x)
}

class B extends {
  val x: Int = 1
} with A

object Test {
  def main(args: Array[String]): Unit = {
    new B
  }
}

You can rewrite B as:

class B private (val x: Int) extends A {
  def this() = this(1)
}

[dwijnand]

It might be worth seeing how much code in the community build depends on early initialisers, and if it can be rewritten.

Either Martin or Adriaan asked at Scala Days NYC something along the lines of "Do you depend on early initialisers?" and no one raised their hand.

[som-snytt]

Thanks for the additional motivation on timing the deprecation.

I wish Adriaan had asked the crowd whether anyone pays attention to deprecations.

I just updated the check files in the PR, and I'm willing to tweak the 2.13 message to whatever is deemed useful.

I don't supposed anyone will come up with a Scalafix for the migration...

[dwijnand]

See scalacenter/scalafix#62

[som-snytt]

That was quite valiant.

[odersky]

Actually, there was someone from Expedia at ScalaDays who said that they use early initiliazers all over the place in their code base. We sat together and I looked at their code. It looked like it could be rewritten using secondary constructors but the result was a bit longer, involving some code duplication. So, it was a clever construct that they were using but there is a workaround. Not a shopstopper, I think. Cheers - Martin

…

On Thu, Jul 5, 2018 at 5:45 PM, Dale Wijnand ***@***.***> wrote: It might be worth seeing how much code in the community build depends on early initialisers, and if it can be rewritten. Either Martin or Adriaan asked at Scala Days NYC something along the lines of "Do you depend on early initialisers?" and no one raised their hand. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#513 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAwlVsgV6PMbytp914PIsy9AkUg6vw5iks5uDjSBgaJpZM4T_Sjg> .

-- Martin Odersky EPFL and Lightbend