What's left behind

[nafg]

At this point, what won’t be supported by Dotty and what are the workarounds?

The main thing that comes to mind is macros that add members like Monocle’s @Lenses. In my understanding that won’t be possible any more. However I rely on it pretty heavily. It would be a huge loss not to have it.

Is there any good solution?

And, are there any other capabilities that are being left behind? What are they, and what is the migration plan?

[Sciss]

Non-concrete-class type projection’s have been axed :-/

Scastie - An interactive playground for Scala

As workaround, usually passing around a value and using path-dependent type would be suggested. I’m still hoping that erased values will make it and be admissable for path-dependent types. (thread)

[AMatveev]

@nafg

macros

White box macro allows extend language injection capability for scala. It is very sad that there are no alternatives.
Proposal to disallow class shadowing will make migration significantly difficult for us.
There will be no rewriting tools.
The service traits will be visible in user code.
We need manually distinguish names.
We will need to rewrite about 4000-8000 traits

@smarter

A given instance without type parameters or given clause is initialized on-demand, the first time it is accessed. It is not required to ensure safe publication, which means that different threads might create different instances for the same given definition. If a given definition has type parameters or a given clause, a fresh instance is created for each reference.

It is also very sad improvements.
We will have to rewrite our core libraries to convert contexts into context providers.

It seems that migration will be the challenge for us.

[martijnhoekstra]

There is a link on the dotty doc pages on dropped features, starting here: https://dotty.epfl.ch/docs/reference/dropped-features/delayed-init.html

Briefly, and uncategorized on whether the last word has been said on the matter, deprecation or removed:

• delayed-init. workaround: regular method call
• scala2 macros. replacement: scala3 metaprogramming (including whitebox-inline).
• existential types. workaround: model as classes
• type projections on abstract types. workaround: path dependent types and/or implicits
• do-while. replacement: fake answer: while. real answer: nothing. Nobody used it.
• package objects. replacement: top-level definitions.
• early initializers. workaround: trait parameters
• class shadowing. workaround: use a different class name
• auto-application (i.e foo calls foo()). workaround: built-in rewrite option in dotty
• weak conformance. workaround: .toDouble
• nonlocal return. workaround: scala.util.control.NonLocalReturns.throwReturn
• private[this]/protected[this]. replacement: none

[nafg]

Right so many of those have straightforward automatic or manual rewrites. My question is about things that have no good equivalent, again like @Lenses.

[kai]

• package objects. replacement: top-level definitions.

The Real replacement for package objects is exports. There’s still nothing definite about a replacement for package object’s implicit priorities, though.

[kai]

The only thing that stops someone from reimplementing macro-paradise in two lines of the new compiler plugin API is that the powerful form of plugins is only available on nightly releases. The solution to that is simple – everyone will just use nightly like it’s Rust! That, or republished compiler binaries with prohibition turned off.