Type parameters via intersection types crash the compiler

[LPTK]

Apparently the syntax class Cont[type A] has been removed. So I wrote this:

class Cont[A0](val x: A0) { type A = A0 }
val c: Cont[_] & { type A = Int } = new Cont(1)
c.x : Int

It fails to compile with "found: c.A0(c.x); required: Int".
So I tried this:

class Cont[A0](x0: A0) { type A = A0; val x: A = x0 }

But the compiler crashes with:

assertion failure for (Cont[_] & Object{A = Int})(c) <:< ?{ x: ? }, frozen = false
[info]
[info] (Cont[_] & Object{A = Int})(c) is a class dotty.tools.dotc.core.Types$TermRefWithFixedSym
[info]
[info] ?{ x: ? } is a class dotty.tools.dotc.typer.ProtoTypes$CachedSelectionProto
[info]
[info] exception occurred while typechecking src/main/scala/Main.scala
[info]
[info] exception occurred while compiling src/main/scala/Main.scala
java.lang.AssertionError: NoDenotation.owner
	at dotty.tools.dotc.core.SymDenotations$NoDenotation.owner(SymDenotations.scala:1816)

[smarter]

Thanks for the report! The syntax you want is probably:

val c: Cont[_] { type A = Int } = new Cont(1)

But of course we shouldn't crash when you use an intersection.

[LPTK]

Thanks for the answer. Are these not supposed to be equivalent, though? Is there a formal specification of the ways in which they diverge?

[smarter]

In theory I'd expect them to be equivalent yeah, in practice though, who knows ¯\_(ツ)_/¯

[LPTK]

Here is one that still makes the compiler crash:

val c: { type A; val x: A } & { type A = Int } = new Cont(1)

Also, why does the following not type check? val c: { val x: Int } = new Cont(1); c.x

11 |    c.x : Int
   |    ^
   |    found:    Object{x: Int}(c)
   |    required: Selectable

EDIT: I guess that one is because of this change in Dotty, so it seems legit.

[smarter]

Yeah, structural types are pretty different in Dotty and probably need more work. Could you open an issue for the crash you got?

[smarter]

Some documentation on structural types: http://dotty.epfl.ch/docs/reference/changed/structural-types.html

[LPTK]

Could you open an issue for the crash you got?

Sure, but why not reopen this one? AFAICT this is another manifestation of the same problem (assertion failure with NoDenotation.owner).

[smarter]

No, it's pretty different since it only affects structural types, and it happens much later in the compiler pipeline (during erasure and not typechecking)

[LPTK]

Ok. I was confused by the output message exception while typing c.x of class class dotty.tools.dotc.ast.Trees$Select but now I see it's raised from ReTyper.