Dependent type isn't inferred correctly in the body
See original GitHub issueCompiler 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
Expectation
p
, which has the same type signature as the return type, gets inferred correctly.
Issue Analytics
- State:
- Created a year ago
- Comments:6 (1 by maintainers)
Top 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 >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
To illustrate why this isn’t actually a bug:
With the match type, we are providing proof of a refined type for a shadowed value
x
. That refined type does not automatically correspond toX
, as evidenced by bothx
andy
in my modified code having typeX
but having different concrete types.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.