Another is not a class type error when creating an anonymous subclass of an abstract class via new through a type alias

[neko-kai]

Compiler version

3.4.0

Minimized code

https://scastie.scala-lang.org/gxYxc2GGSL2Kakv3xDQyKA

final abstract class ForcedRecompilationToken[T]
object ForcedRecompilationToken {
  implicit def default: ForcedRecompilationToken["abc"] = null
}

object x {
  abstract class GoodNoParens[T](implicit ev: ForcedRecompilationToken[T])
}
type BadNoParens[T] = x.GoodNoParens[T]

object App extends App {
  // error
  new BadNoParens {}

  // ok
  new BadNoParens() {}
  new x.GoodNoParens {}

  println("compiled")
}

Output

x.GoodNoParens is not a class type

Expectation

Same issue as in #18623, but this time it's when instantiating via new instead of declaring an object.

[odersky]

Since it looked similar #18623, I had a look at it. Unfortunately, here we see a completely different code path since this is a new {} expression. It will be quite messy to fix this. Maybe we should not even try.

[neko-kai]

@odersky As with the previous issues in this series, this also affects export statements and makes them unreliable.

https://scastie.scala-lang.org/jn9DzwGoR4WW7wrFB4ERFg

final abstract class ForcedRecompilationToken[T]
object ForcedRecompilationToken {
  implicit def default: ForcedRecompilationToken["abc"] = null
}

object x {
  abstract class GoodNoParens[T](implicit ev: ForcedRecompilationToken[T])
}
export x.GoodNoParens as BadNoParens

object App extends App {
  // error
  new BadNoParens {}

  // ok
  new BadNoParens() {}
  new x.GoodNoParens {}

  println("compiled")
}

This worked correctly on Scala 2 and is still blocking me from porting existing library code to Scala 3...[1]

[odersky]

Can't you just write new BadNoParents() everywhere?

[neko-kai]

@odersky Well, not really, in the real-world use case the type parameter, the implicit, the parens (that aren't even actually present in the class header either) are all implementation details that the user doesn't have to even know about. In worst case, I will have to remove the export - not force the user to write parentheses.

In the abstract case, I'm not sure export has to be leaky - especially in cases where type aliases worked correctly before, in Scala 2.

[neko-kai]

So far I had to remove type aliases / exports in our Scala 3 port because of this issue. Maybe this could be addressed at some point? It really breaks the export abstraction for classes if their constructors are used in a DSL.