Opaque type not transparent in its defining scope, when referred to via qualified name

[TomasMikula]

Compiler version

3.3.1
3.3.2-RC3
3.4.0-RC4

Minimized code

object o {
  opaque type T = String

  summon[o.T =:= T]      // OK
  summon[o.T =:= String] // OK

  def test1(t: T): Int =
    t.length // OK

  def test2(t: o.T): Int =
    t.length // Error: value length is not a member of Playground.o.T
}

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

Output

value length is not a member of Playground.o.T

Expectation

According to https://docs.scala-lang.org/scala3/reference/other-new-features/opaques-details.html#type-checking-10

we have inside the object (also for non-opaque types) that o.T is equal to T or its expanded form o.this.T. Equality is understood here as mutual subtyping, i.e. o.T <: o.this.T and o.this.T <: o.T. Furthermore, we have by the rules of opaque type aliases that o.this.T equals R. The two equalities compose. That is, inside o, it is also known that o.T is equal to R.

it should hold, inside the object o, that o.T is equal to o.this.T is equal to String. Therefore, t.length should typecheck.

[bishabosha]

Edit: im hiding my original statement because o.Foo != o.this.Foo if you use the compilers internal API, but I guess I'm not sure what happens if you write it in the source code

[sjrd]

There is a difference between the internal type system (at the TASTy level, let's say) and the external type system that the users see. In the internal type system, only o.this.T can see the alias. But at the user level, the elaboration is supposed to make o.T =:= o.this.T appear to be true as well, and insert casts if necessary.

@dwijnand I think you looked at a similar issue not too long ago. Does this ring a bell?

[dwijnand]

I can't remember what you might be remembering. But I found a fix for this.