question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Dependent type isn't inferred correctly in the body

See original GitHub issue

Compiler version

3.2.0

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(0))
  case x: Iterable[t] => leafElem(x.head)
  case x: AnyVal      => {
    val p: LeafElem[X] = x
    p
  }

Output

the p is not inferred correctly

image

Expectation

p, which has the same type signature as the return type, gets inferred correctly.

Issue Analytics

  • State:closed
  • Created a year ago
  • Comments:6 (1 by maintainers)

github_iconTop GitHub Comments

1reaction
markehammonscommented, Sep 27, 2022

To illustrate why this isn’t actually a bug:

type LeafElem[X] = X match
  case String => Char
  case Int => Float


def leafElem[X](x: X, y: X): LeafElem[X] = x match
  case x: String      => x.charAt(0)
  case x: Int           => {
     val p: LeafElem[Int] = y.asInstanceOf[Int].toFloat
     p
  }

//class cast exception: Class java.lang.String cannot be cast to Integer
leafElem(4, "hello")

With the match type, we are providing proof of a refined type for a shadowed value x. That refined type does not automatically correspond to X, as evidenced by both x and y in my modified code having type X but having different concrete types.

1reaction
som-snyttcommented, Sep 27, 2022
   |                           trying to reduce  LeafElem[X]
   |                           failed since selector  X
   |                           does not match  case String => Char
   |                           and cannot be shown to be disjoint from it either.

Intersectionless Scala 2 disallows the pattern match on AnyVal.

In Scala 3, the pattern match really means Any, but it doesn’t warn me about that.

Read more comments on GitHub >

github_iconTop Results From Across the Web

TypeScript inference doesn't work properly - Stack Overflow
Firstly the inferred signature of handleSomeValue is <T>(obj: OptionValue<T>) => T | "empty" . Notice there is no relation between T and whether ......
Read more >
Type tuples no longer inferred properly from rest arguments ...
I recently updated the dependencies for a TypeScript-based project and unfortunately ended up with some unexpected breakage.
Read more >
Scala 3: Dependent Types, Part II | by Dean Wampler - Medium
Disclaimer: I'm no expert on dependent typing. There are probably lots of naive mistakes in this post. I welcome feedback!
Read more >
Compositional and Lightweight Dependent Type Inference for ...
Our verification strategy is based on a counterexample-guided refinement loop that systematically strengthens a function's inferred dependent type based on new ...
Read more >
Dependent Types: Easy as PIE - Penn Engineering
sive power, dependent types have not yet advanced into mainstream ... binds a new variable, so the body of the abstraction is one...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found