"<type alias> does not take type parameters" when type parameter is same as the companion object for top-level type aliases

[unkarjedy]

Scala 3.7.2

Notice that MyOutputAlias2[MyType] is not compiled when put inside MyType.
I am not 100% sure it's against some part of specification, but it feels off.
I noticed this inconsistency while playing around with example from SCL-22391

trait MyOutput[T]
final type MyOutputAlias1[T] = MyOutput[T]
final type MyOutputAlias2 = MyOutput

trait MyType
object MyType {
  val value1: MyOutput[MyType] = ???
  val value2: MyOutputAlias1[MyType] = ???
  val value3: MyOutputAlias2[MyType] = ??? // COMPILATION ERROR
}

val value1: MyOutput[MyType] = ???
val value2: MyOutputAlias1[MyType] = ???
val value3: MyOutputAlias2[MyType] = ???

Note, all is fine if you wrap the code (making the type alias non-top-level)

object wrapper {
  trait MyOutput[T]
  final type MyOutputAlias1[T] = MyOutput[T]
  final type MyOutputAlias2 = MyOutput

  trait MyType
  object MyType {
    val value1: MyOutput[MyType] = ???
    val value2: MyOutputAlias1[MyType] = ???
    val value3: MyOutputAlias2[MyType] = ???
  }

  val value1: MyOutput[MyType] = ???
  val value2: MyOutputAlias1[MyType] = ???
  val value3: MyOutputAlias2[MyType] = ???
}

[mbovel]

Reproduced with the latest nightly. Here is the error, along with the trees after typer:

$ scala -Xprint:typer -S 3.nightly test.scala
Compiling project (Scala 3.8.1-RC1-bin-20251124-608e8d8-NIGHTLY, JVM (17))
Warning: Option -Xprint is a deprecated alias: use -Vprint instead
[error] ./test.scala:9:15
[error] MyOutputAlias2 does not take type parameters
[error]   val value3: MyOutputAlias2[MyType] = ??? // COMPILATION ERROR
[error]               ^^^^^^^^^^^^^^^^^^^^^^
[[syntax trees at end of                     typer]] // /localhome/bovel/scala3/test.scala
package <empty> {
  trait MyOutput[T >: Nothing <: Any]() extends Object {
    T
  }
  trait MyType() extends Object {}
  final lazy module val MyType: MyType = new MyType()
  final module class MyType() extends Object() { this: MyType.type =>
    val value1: MyOutput[MyType] = ???
    val value2: MyOutputAlias1[MyType] = ???
    val value3: MyOutputAlias2 = ???
  }
  final lazy module val test$package: test$package = new test$package()
  final module class test$package() extends Object() {
    this: test$package.type =>
    final type MyOutputAlias1[T >: Nothing <: Any] = MyOutput[T]
    final type MyOutputAlias2 = MyOutput
    val value1: MyOutput[MyType] = ???
    val value2: MyOutputAlias1[MyType] = ???
    val value3: MyOutputAlias2[MyType] = ???
  }
}

Maybe the check doesn't dealias MyOutputAlias2 to MyOutput for some reasons?

Note that after desugaring, both end up in different places: MyOutput is in the top-level <empty> package, while MyOutputAlias2 is in the test$package() class.

[mbovel]

I am wondering if that could be loosely related to #24056, where there also is a problem following aliases when computing the number of types arguments.

[mbovel]

This issue was picked for the Scala Compiler Spree of today, November 24. @mbovel and @HarrisL2 will be working on it. If you have any insight into the issue or guidance on how to fix it, please leave it here.

[mbovel]

Minimized to:

trait MyOutput[T]
type MyOutputAlias2 = MyOutput

object MyType:
  val value3: MyOutputAlias2[String] = ??? // COMPILATION ERROR

sbt:scala3-nonbootstrapped> scalac -Vprint:typer playground.scala
[info] running (fork) dotty.tools.dotc.Main -d /localhome/bovel/scala3/out/default-last-scalac-out.jar -classpath /localhome/bovel/scala3/library/target/scala-library-nonbootstrapped/scala-library-3.8.1-RC1-bin-SNAPSHOT-nonbootstrapped.jar -Vprint:typer playground.scala
-- [E053] Type Error: playground.scala:7:14 ------------------------------------
7 |  val value3: MyOutputAlias2[String] = ??? // COMPILATION ERROR
  |              ^^^^^^^^^^^^^^^^^^^^^^
  |              MyOutputAlias2 does not take type parameters
  |
  | longer explanation available when compiling with `-explain`
[[syntax trees at end of                     typer]] // playground.scala
package <empty> {
  trait MyOutput[T >: Nothing <: Any]() extends Object {
    T
  }
  final lazy module val MyType: MyType = new MyType()
  final module class MyType() extends Object() { this: MyType.type =>
    val value3: MyOutputAlias2 = ???
  }
  final lazy module val playground$package: playground$package =
    new playground$package()
  final module class playground$package() extends Object() {
    this: playground$package.type =>
    type MyOutputAlias2 = MyOutput
  }
}
1 error found
[error] nonzero exit code returned from runner: 1
[error] (scala3-compiler-nonbootstrapped / Compile / runMain) nonzero exit code returned from runner: 1
[error] Total time: 3 s, completed Nov 24, 2025, 4:24:11 PM

[mbovel]

Desugaring probably happens there:

scala3/compiler/src/dotty/tools/dotc/ast/Desugar.scala

Lines 1866 to 1876 in ce94491

	/** Group all definitions that can't be at the toplevel in
	* an object named `<source>$package` where `<source>` is the name of the source file.
	* Definitions that can't be at the toplevel are:
	*
	* - all pattern, value and method definitions
	* - non-class type definitions
	* - implicit classes and objects
	* - "companion objects" of wrapped type definitions
	* (i.e. objects having the same name as a wrapped type)
	*/
	def packageDef(pdef: PackageDef)(using Context): PackageDef = {

[mbovel]

During the Spree, we found the origin of the error.

TypeDefCompleter.completerTypeParams tries its best to infer the type parameters by looking at the structure of the untyped TypeDef. If it fails, it returns Nil:

scala3/compiler/src/dotty/tools/dotc/typer/Namer.scala

Lines 1055 to 1075 in ae54faa

	override def completerTypeParams(sym: Symbol)(using Context): List[TypeSymbol] =
	if myTypeParams == null then
	//println(i"completing type params of $sym in ${sym.owner}")
	nestedCtx = localContext(sym).setNewScope
	given Context = nestedCtx.uncheckedNN
	def typeParamTrees(tdef: Tree): List[TypeDef] = tdef match
	case TypeDef(_, original) =>
	original match
	case LambdaTypeTree(tparams, _) => tparams
	case original: DerivedFromParamTree => typeParamTrees(original.watched)
	case _ => Nil
	case _ => Nil
	val tparams = typeParamTrees(original)
	index(tparams)
	myTypeParams = tparams.map(symbolOfTree(_).asType)
	for param <- tparams do typedAheadExpr(param)
	end if
	myTypeParams.uncheckedNN
	end completerTypeParams

That function is called from TypeApplications.typeParams:

scala3/compiler/src/dotty/tools/dotc/core/TypeApplications.scala

Lines 181 to 198 in ae54faa

	try self match {
	case self: TypeRef =>
	val tsym = self.symbol
	if (tsym.isClass) tsym.typeParams
	else tsym.infoOrCompleter match {
	case info: LazyType if isTrivial(self.prefix, tsym) =>
	val tparams = info.completerTypeParams(tsym)
	if tsym.isCompleted then tsym.info.typeParams
	// Completers sometimes represent parameters as symbols where
	// the completed type represents them as paramrefs. Make sure we get
	// a stable result by calling `typeParams` recursively. Test case
	// is pos/i19942.scala, where parameter F0 has initially a Namer#TypeDefCompleter.
	// After calling its completerTypeParams, we get a list of parameter symbols
	// and as a side effect F0 is completed. Calling typeParams on the completed
	// type gives a list of paramrefs.
	else tparams
	case _ => self.info.typeParams
	}

Which is called from Typer.typedAppliedTypeTree:

scala3/compiler/src/dotty/tools/dotc/typer/Typer.scala

Lines 2679 to 2691 in ae54faa

	def typedAppliedTypeTree(tree: untpd.AppliedTypeTree)(using Context): Tree = {
	val tpt1 = withoutMode(Mode.Pattern):
	typed(tree.tpt, AnyTypeConstructorProto)
	val tparams = tpt1.tpe.typeParams
	if tpt1.tpe.isError then
	val args1 = tree.args.mapconserve(typedType(_))
	assignType(cpy.AppliedTypeTree(tree)(tpt1, args1), tpt1, args1)
	else if (tparams.isEmpty) {
	report.error(TypeDoesNotTakeParameters(tpt1.tpe, tree.args), tree.srcPos)
	tpt1
	}
	else {

Where we throw an error because tparams == Nil.

This the case because the specific desugaring shown above results in a completion order where MyOutputAlias2 is not completed when val value3: MyOutputAlias2[String].

[mbovel]

During the Spree, we tried to fix the completer by typing original ahead and getting the type parameters from the result's type symbol:

    override def completerTypeParams(sym: Symbol)(using Context): List[TypeSymbol] =
      if myTypeParams == null then
        nestedCtx = localContext(sym).setNewScope
        given Context = nestedCtx.uncheckedNN

        def go(tdef: Tree): Unit = tdef match
          case TypeDef(_, original) =>
            original match
              case LambdaTypeTree(tparams, _) =>
                index(tparams)
                myTypeParams = tparams.map(symbolOfTree(_).asType)
                for param <- tparams do typedAheadExpr(param)
              case original: DerivedFromParamTree =>
                go(original.watched)
              case _ =>
                val originalTp = typedAheadType(original).tpe
                val originalSymbol = originalTp.typeSymbol
                val originalTparams = originalSymbol.typeParams
                println(originalTparams)
                myTypeParams = originalTparams
          case _ =>
            myTypeParams = Nil

        go(original)
      end if
      myTypeParams.uncheckedNN
    end completerTypeParams

That seems to work locally, but triggers a Missing type parameter error later 😅:

-- [E056] Syntax Error: playground2.scala:15:14 --------------------------------
15 |  val value3: MyOutputAlias2[MyType] = ???
   |              ^^^^^^^^^^^^^^^^^^^^^^
   |              Missing type parameter for O.MyOutputAlias2[O.MyType]

[mbovel]

Further thinking about it, I am wondering if it wouldn't be simpler to just dealias tpt1.tpe in Typer.typedAppliedTypeTree, avoiding the issue of the alias completer altogether. I tried it in #24522.

[mbovel]

During the Spree discussion, @hamzaremmal also raised a broader question: should we support higher-kinded type aliases in the first place? And if yes, shouldn’t they be automatically eta-expanded into type lambdas?