Skip to content

Match types are broken (or documentation is wrong) #11438

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
tabdulradi opened this issue Feb 17, 2021 · 2 comments · Fixed by #11463
Closed

Match types are broken (or documentation is wrong) #11438

tabdulradi opened this issue Feb 17, 2021 · 2 comments · Fixed by #11463

Comments

@tabdulradi
Copy link

Hello 👋 I copied Match types example from the docs into Scastie, but it didn't compile.

Compiler version

3.0.0-M3

Minimized code

type LeafElem[X] = X match
   case String => Char
   case Array[t] => LeafElem[t]
   case Iterable[t] => LeafElem[t]
   case AnyVal => X

def leafElem[X](x: X): LeafElem[X] = x match
   case x: String      => x.charAt(0)
   case x: Array[t]    => leafElem(x(9))
   // case x: Iterable[t] => leafElem(x.next())
   case x: AnyVal      => x

Output

Found: Char
Required: LeafElem[X]
where: X is a type in method leafElem with bounds >: (?1 : String)

Found: t
Required: X
where: X is a type in method leafElem with bounds >: (?2 : Array[t])

Found: (x : X & AnyVal)
Required: LeafElem[X]
where: X is a type in method leafElem with bounds >: (?3 : AnyVal)

Expectation

Code should compile

@OlivierBlanvillain
Copy link
Contributor

OlivierBlanvillain commented Feb 18, 2021

There is a typo in the docs, it should be .head and not .next() (the next method is not defined on scala.collection.Iterable).

However I don't think the code you wrote in the issue should compile, the match expression has one less case than the match type, so it doesn't fulfill the 3rd requirement stated in the Dependent Typing section (the match expression and the match type have the same number of cases).

@LPTK
Copy link
Contributor

LPTK commented Feb 18, 2021

@OlivierBlanvillain it would be really helpful if the compiler could give the reason why the match could not be type-checked successfully, in the original code. Instead, it currently yields many errors that point the programmer in the wrong direction. I did not know there was special reasoning in the compiler for making matches in types and terms match, so I thought the problem was with GADT-style reasoning and the like (as the errors seemed to imply).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants