Unsoundness for singletons? Regression from #16664

[soronpo]

#16664 attempts to fix possible unsoundness issues, but I think it is too limiting.
Consider the following code that relies on singleton type from the parent class parameter.

Compiler version

3.3.1-RC1-bin-20230301-0df5ae2-NIGHTLY

Minimized code

def tuple1[D <: Int with Singleton](arg: D): Tuple1[D] = ???
class Container[T](arg: T)
class Extender[C <: Int with Singleton](val argC: C) extends Container(tuple1(argC)) //error

If we explicitly apply the type argument, this compiles fine:

def tuple1[D <: Int with Singleton](arg: D): Tuple1[D] = ???
class Container[T](arg: T)
class Extender[C <: Int with Singleton](val argC: C) extends Container[Tuple1[C]](tuple1(argC)) //no error

Output

The type of a class parent cannot refer to constructor parameters, but Container[Tuple1[(Extender.this.argC : C)]] refers to argC

Expectation

No error.
Note: Scala 2 also fails in the same situation (with a different error), but I don't see the how unsoundness is formed with singletons.

[sjrd]

The error that is reported is definitely correct, given the inferred type. If you explicitly write the type that gets inferred, i.e., Container[Tuple1[argC.type]], it would (should) rightfully complain. The type you wrote explicitly was Container[Tuple1[C]], which does not refer to argC and is therefore fine.

Now the type that does get inferred is clearly not the best one in this specific example. If type inference inferred Container[Tuple1[C]] instead of Container[Tuple1[argC.type]], the original example would compile. The inference is caught between a rock and a hard place: it is instructed to select a singleton type because of the Singleton bound, but it the singleton type it infers is not valid in this context.

[soronpo]

Is it right to say that we need to change the inference mechanism so:

• for each class argument a that is applied in an extension of a another class, its most precise inferred type will never be a.type

?

[sjrd]

Only within the parent class type. It's still possible to soundly use a.type in the body of the class, or even within super constructor arguments.