Inherited method on objects does not work when using a match type alias.

[Iltotore]

Compiler version

3.3.0 (also tested in 3.2.2)

Minimized code

See https://github.com/Iltotore/scala3-object-bug/

Output

The main module compiles

The dependent module does not.

Note: removing the match type in type alias works. However, this is disturbing when the match type is relevant.

Expectation

The Main.scala file is the same in both module. I would expect the one in dependent to compile like the one in main.

[Iltotore]

The error message:

[error] -- [E050] Type Error: C:\Users\rapha\Downloads\scala3-object-bug\dependent\src\Main.scala:5:14
[error] 5 |    val bar = Bar("yes")
[error]   |              ^^^
[error]   |              object Bar does not take parameters
[error]   |
[error]   | longer explanation available when compiling with `-explain`

[sjrd]

Copy-pasting from the repo for a global view:

// Foo.scala
type Foo[T] = T match
  case _ => FooImpl[T]

trait FooImpl[A]:
  def apply(value: String): Any = ???

// Bar.scala

trait Bar

object Bar extends Foo[Bar]

// Main.scala
// compiles when compiled together with the other files,
// but not under separate compilation

object Main:
  @main
  def testMain =
    val bar = Bar("yes") // "object Bar does not take parameters"
    println(bar)

TBH, I'm not sure the definition of Bar is supposed to compile in the first place. Types in extends clauses must be (parametrized) class types, or aliases thereof. Using a match type there, even if it happens to resolve to a class type, is probably not right.

My suggestion here would be to disallow the definition of Bar. I don't think there is anything in the spec that supports this usage.

@dwijnand WDYT?

[sjrd]

Thinking about it, there seems to be a similar hole with opaque type aliases:

scala> object Foo { class Super[A] { def sup: A = null.asInstanceOf[A] }; opaque type SuperOpaque = Super[String]; class Child extends SuperOpaque }
// defined object Foo

scala> val c = new Foo.Child
val c: Foo.Child = Foo$Child@67dc6b48

scala> c.sup
val res0: String = null

This shows that the alias behind SuperOpaque escapes its defining scope through being used in an extends clause, and therefore leaking through baseType.

We should forbid that kind of ill-defined extends clause.

[dwijnand]

Types in extends clauses must be (parametrized) class types, or aliases thereof.

It is an alias, except it's a match alias application rather than a type alias application. So I don't see why it shouldn't compile.

The reason for the difference between joint and separate is, again, because of the simplify that's in typer and not in treeunpickler - which I'm trying to address.

This shows that the alias behind SuperOpaque escapes its defining scope through being used in an extends clause, and therefore leaking through baseType.

I agree, actually (after initially disagreeing 😄). I finally disagreed when I thought about:

scala> val c1: Foo.SuperOpaque = c
-- [E007] Type Mismatch Error: -------------------------------------------------
1 |val c1: Foo.SuperOpaque = c
  |                          ^
  |                          Found:    (c : Foo.Child)
  |                          Required: Foo.SuperOpaque
  |
  | longer explanation available when compiling with `-explain`
1 error found

So probably the SuperOpaque parent is being dealiased too early and eagerly.

[sjrd]

It is an alias, except it's a match alias application rather than a type alias application. So I don't see why it shouldn't compile.

A match alias is nothing but a type alias to a match type. It is not an alias to the reduction of that match type. A match type is not a class type.

Unless of course we specifically broaden the definition of what a "class type" is to include a "match type that reduces to a class type". If we do that, then, when combined with the fact that a "class type" can also be an "alias to a class type", then we'll get that an alias to a match type that reduces to a class type will be a class type as well. But I'm a bit afraid of the consequences here. For example, what if the match type reduces only because we can see the underlying alias of an opaque type alias? It becomes much more complicated to specify what can be used in an extends clause, or even in a match type case pattern (yielding more circular spec shenanigans).

[dwijnand]

I'd say the most conservative: only if it reduces in, not sure what to call it, the "global context" - i.e. with no privileged knowledge. But that basically means only if the match type is trivial - and, although we support the definition of trivial, auto-reducing, match types, I don't see why we need to extend that support to supporting their usage as parents. 👍

[Iltotore]

For your interest, here is the original use case:

In a project introducing refined types, I emulated zero-overhead-newtypes using opaque types:

opaque type Temperature = Int :| Positive

Note: A :| C is a type A with a constraint C

And provided a trait named RefinedTypeOpsImpl[A, C, T] where:

• A is the base type
• C is the constraint type
• T is the final type (Temperature)

This trait adds several utility methods like smart constructors (Temperature(...), Temperature.either(...), ...).

So we get:

opaque type Temperature = Int :| Positive
object Temperature extends RefinedTypeOpsImpl[Int, Positive, Temperature]

But this quickly become redundant and boilerplaty to write the base type and the constraint type two times, especially when the constraint is less trivial. So I made the following type alias:

type RefinedTypeOps[T] = T match
  case a :| c => RefinedTypeOpsImpl[a, c, T]

Now, the sample above becomes:

opaque type Temperature = Int :| Positive
object Temperature extends RefinedTypeOps[Temperature]

It works when in the same module and not compiling incrementally, but when I try to use the inherited methods like apply... I get this error.

[sjrd]

So you're successfully exploiting the two holes I highlighted above: the one with match types, and the one with opaque type aliases. And whereas the one with match types is debatable, the one with opaque type aliases is clearly a hole we need to plug.

I strongly recommend that you use the "boilerplate" instead.