-Xsource:3.0 overview

[adriaanm]

For migration to 3.0, Scala 2.14 (or perhaps 2.13 where feasible) should offer a source level that does the following:

• disallow:
  • procedure syntax
  • early initializers (once we'll have trait parameters)
  • xml literals
  • implicit class member without explicit return type (perhaps still infer from RHS if it's new T)
• newly reserved keywords:
  • explicitly
  • inline
• explicitly to indicate implicit arguments is being passed explicitly (if not, assume we're passing in explicit arguments, and infer implicit ones)
• free up _ for type lambdas (kind-projector has to use ?, but _ would be more logical if we can migrate)
• accept & for with
• repeated argument syntax for patterns xs@ _* --> xs: _*
• name clashes of class members (they're not overrides, disallow) (see #156)

  class C { class I }
  class D extends C { class I /* <-- needs unique name */ }
  

[adriaanm]

/cc FYI @odersky, @densh (for xml literal deprecation), @DarkDimius, @smarter

[olafurpg]

Would it be possible to introduce deprecation warnings for the most simple syntactic changes in 2.12.x?

procedure syntax

Already implemented in scalafix (since v0.1).

repeated argument syntax for patterns xs@ _* --> xs: _*
accept & for with

Should be easy to implement.

xml literals

I believe there has been made some recent progress on an xml interpolator here: https://github.com/densh/scala-xml-quote once the interpolator is ready, I'm optimistic it will be possible to provide a scalafix migration for it.

implicit class member without explicit return type (perhaps still infer from RHS if it's new T)

This is currently implemented in not such a robust way with the scalafix-nsc compiler plugin. However, the scala.meta semantic api will soon add support for denotations (see scalameta/scalameta#808), which scalafix will switch to very soon.

[adriaanm]

We'll target 2.13 for these features unless there's a compelling reason to have this in 2.12. 2.12.x is now only for bug fixes and performance improvements, in principle.

[smarter]

Some other things to consider:

• If the return type of an override is omitted, it is set to the return type of the overriden member instead of inferred from its rhs:

trait A { def foo: Any }
class B extends A { def foo = "hi" } // B#foo has type String in scalac, but Any in dotty

• Abstract vals cannot be overriden by lazy vals (Change is volatile scala3#1051)
• Only final lazy vals can be path (Change is volatile scala3#1051)

[smarter]

Abstract vals cannot be overriden by lazy vals (scala/scala3#1051)

To be usable without losing too much power, this require supporting abstract lazy vals which scalac doesn't so far.

[DarkDimius]

Related: scala/scala3#1473

[smarter]

One more: Implicit vals of type Function1 are no longer considered when looking for implicit conversions, instead an explicit ImplicitConverter class is provided: scala/scala3#2065

[SethTisue]

I don't see "scala.reflect-based macros" on either this or the Dotty ticket

[adriaanm]

One of the big differences in the ABI would be solved by #408 (see dotty's AugmentScala2Traits phase). Other issue is name mangling in certain cases.

[dwijnand]

2.14 isn't going to happen, so some of these have to be done in 3.0 instead. Some of these have actually already landed (such as non-overriding inner classes). Contributions here would be welcome, but I don't think we need a holder ticket open for this anymore. Also, the Scala Center is putting some efforts in, see scalacenter/scala-3-migration-guide.

[SethTisue]

These migration scenarios can be addressed in multiple ways. We can lint or deprecate in Scala 2, without requiring -Xsource:3 to be enabled; for example, we did that with procedure syntax. We can put things under -Xsource:3. And, we can defer the problem and let Dotty warn when constructs that are unsupported or may not continue to be supported in future 3.x versions. In practice, I think that enabling -Xsource:3 is something that most users won't even do unless we were to push it at them really hard, so in general, I think the other two approaches are usually preferable.